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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

jratike80

Hi,

 

The thread “Considering drivers removal ?” made me think about what is the real issue. Is there something fundamentally wrong with the current GDAL? If having >100 and >100 drivers prevent developers from doing modernization in GDAL internals I do not believe that having 90 and 90 really makes much difference. Not even what Even suggested “We should probably trim down the list to 20 raster and vector drivers to have a real effect regarding that.”

 

What if we imagine that we have managed to drop all the drivers and we have free hands to modernize the GDAL internals and everything. What would we do differently? Would there be less built-in drivers and more plugins or what?

And when it comes the time to do the next modernization campaign, would it be any easier? How about the threshold to become a maintainer? I am not a developer myself but somehow I feel that currently it is not so easy to jump in and start maintaining even just one specific driver.

 

-Jukka Rahkonen-

 

 


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Howard Butler-3

Is there something fundamentally wrong with the current GDAL?

The project's history is one person doing most of the work. This person eventually burns out.

Here's a table of the top five lifetime commits to the repository as of December 2020. 

Even Rouault – 19,838
Frank Warmerdam – 11,503
Kurt Schwehr – 3,403
Andrey Kiselev – 1,320
Howard Butler – 768

The reason why this person burns out is they are actually doing *three* jobs, not one. Three, you say? 

First is the actual maintainer job. You're the clearinghouse for bugs, the primary authority on the mailing list, the first respondent in the bug tracker, and the one that organizes and cuts the software release. When we think of the maintainer for the GDAL project, this is what we think of. No one organization will pay for just this job.

This means you need a revenue stream to make it maintenance your full time gig. That's easy enough, just get paid for working on GDAL, right? Well sure, but people don't want to pay for you to fix bugs that users vaguely provide in the mailing list. They want to pay for functionality they need to add to their software. So you are in a spot – you have to *add* more to the software to earn revenue. For GDAL, adding more means more drivers and more capabilities for those drivers (CPL, VSICloud, etc). This creates more bugs and maintenance load that the original directed funder supports for only a little while. This second job is in conflict with the first and the dissonance amplifies as time goes one.

The third job is you have to solicit work through the contacts you've built up to keep the revenue hopper full. Invoicing, statements of work, negotiation, telecons, and the usual business stuff. People see you as cheap because you're "open source", and pressure you on price, scope, and completion time. You eventually orient about a small cadre of repeat clients with strong trust relationships. 

How can this be fixed?

1) Burn through the current maintainer and hope another one comes along. The users of the GDAL project simply got lucky that Even picked up the torch after Frank moved on. Maybe that happens again on the next iteration.

2) Refactor the software so that more maintainers can participate. That's been our current discussion, which doesn't seem to be converging on any solutions.

3) Provide a revenue stream so the maintainer only has to do the maintenance job, and not the other two jobs that are in conflict with the project's maintenance. This person should be paid like the FAANG senior engineer that's currently taking GDAL and using it to add some geo widget to their software. 

OSGeo was supposed to be the answer to #3, but in 15 years of existence it has shown it is not and never will be. Maybe it is time to start a GDAL foundation ala QGIS and others and direct corporate benefactors to fund it directly. Those benefactors would have to pledge significant resources to at least get to the level of a FAANG senior engineer as a start.

Howard



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Daniel Morissette
Thank you Howard for a great analysis and for pointing out the key problems.

Personally I think the top two problems are:

1- Bus number: we need to find a way to increase the number of active
maintainers to ensure the viability and velocity of the project

2- Sustainable revenue stream for maintenance activities: as you
explained, it is relatively easy to fund features, but profitable
companies selling software or services that use GDAL need to realize
that it would be an investment for them to contribute even just a
fraction of 1% of their sales in "non-string-attached funding" to
support non-sexy stuff such as release management, bug fixes, security
fixes, dependency upgrades, packaging, docs,  etc... not only in GDAL,
but in the top-5 open source components that they rely on.

The QGIS approach to managing funding is an option, but it's not the
only one. I would tend to go for a more decentralized approach to reduce
the risk for the project with a single entity supporting it.

I step up to work with you Howard toward improving the situation.
(Actually I had already written personally to Even to discuss some
options before seeing your reply)

Daniel



On 2021-01-13 12:33, Howard Butler wrote:

>
>> Is there something fundamentally wrong with the current GDAL?
>
> The project's history is one person doing most of the work. This person
> eventually burns out.
>
> Here's a table of the top five lifetime commits to the repository as of
> December 2020.
>
> Even Rouault – 19,838
> Frank Warmerdam – 11,503
> Kurt Schwehr – 3,403
> Andrey Kiselev – 1,320
> Howard Butler – 768
>
> The reason why this person burns out is they are actually doing *three*
> jobs, not one. Three, you say?
>
> First is the actual maintainer job. You're the clearinghouse for bugs,
> the primary authority on the mailing list, the first respondent in the
> bug tracker, and the one that organizes and cuts the software release.
> When we think of the maintainer for the GDAL project, this is what we
> think of. No one organization will pay for just this job.
>
> This means you need a revenue stream to make it maintenance your full
> time gig. That's easy enough, just get paid for working on GDAL, right?
> Well sure, but people don't want to pay for you to fix bugs that users
> vaguely provide in the mailing list. They want to pay for functionality
> they need to add to their software. So you are in a spot – you have to
> *add* more to the software to earn revenue. For GDAL, adding more means
> more drivers and more capabilities for those drivers (CPL, VSICloud,
> etc). This creates more bugs and maintenance load that the original
> directed funder supports for only a little while. This second job is in
> conflict with the first and the dissonance amplifies as time goes one.
>
> The third job is you have to solicit work through the contacts you've
> built up to keep the revenue hopper full. Invoicing, statements of work,
> negotiation, telecons, and the usual business stuff. People see you as
> cheap because you're "open source", and pressure you on price, scope,
> and completion time. You eventually orient about a small cadre of repeat
> clients with strong trust relationships.
>
> How can this be fixed?
>
> 1) Burn through the current maintainer and hope another one comes along.
> The users of the GDAL project simply got lucky that Even picked up the
> torch after Frank moved on. Maybe that happens again on the next iteration.
>
> 2) Refactor the software so that more maintainers can participate.
> That's been our current discussion, which doesn't seem to be converging
> on any solutions.
>
> 3) Provide a revenue stream so the maintainer only has to do the
> maintenance job, and not the other two jobs that are in conflict with
> the project's maintenance. This person should be paid like the FAANG
> senior engineer that's currently taking GDAL and using it to add some
> geo widget to their software.
>
> OSGeo was supposed to be the answer to #3, but in 15 years of existence
> it has shown it is not and never will be. Maybe it is time to start a
> GDAL foundation ala QGIS and others and direct corporate benefactors to
> fund it directly. Those benefactors would have to pledge significant
> resources to at least get to the level of a FAANG senior engineer as a
> start.
>
> Howard
>
>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

David Strip-2
In reply to this post by Howard Butler-3
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Kurt Schwehr-2
I mostly wanted to say that I'm here listening to the discussion and thinking about all these issues.

On the technical side, I tried to publicly think about long term maintainability / reliability of GDAL over the years.  It's always a moving target, but here are a few of my old thoughts:


Those leave out a lot and are dated.

On Wed, Jan 13, 2021 at 12:24 PM David Strip <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Javier Jimenez Shaw
In reply to this post by David Strip-2
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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Nyall Dawson
On Thu, 14 Jan 2021 at 07:26, Javier Jimenez Shaw <[hidden email]> wrote:

> - 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?)

For reference -- QGIS indirectly sponsors improvements and fixes in
GDAL and PROJ by employing Even to work on upstream issues which
impact QGIS during the lead up to any QGIS major release. The project
has recently started doing a similar thing with GEOS through
sponsorship of Sandro Santilli.

Fingers crossed we see more upstream (including non-open-source)
applications follow the same model...

Nyall




>
> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Nyall Dawson
In reply to this post by David Strip-2
On Thu, 14 Jan 2021 at 06:24, David Strip <[hidden email]> 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?

Nyall
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Howard Butler-3


On Jan 13, 2021, at 4:28 PM, Nyall Dawson <[hidden email]> wrote:

On Thu, 14 Jan 2021 at 06:24, David Strip <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Carl Godkin-2
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 <[hidden email]> wrote:


On Jan 13, 2021, at 4:28 PM, Nyall Dawson <[hidden email]> wrote:

On Thu, 14 Jan 2021 at 06:24, David Strip <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

GDAL - Dev mailing list
In reply to this post by Howard Butler-3
Hi Howard and all,

On Wed, Jan 13, 2021 at 3:58 PM Howard Butler <[hidden email]> wrote:


On Jan 13, 2021, at 4:28 PM, Nyall Dawson <[hidden email]> wrote:

On Thu, 14 Jan 2021 at 06:24, David Strip <[hidden email]> 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.

Maybe? Getting shamed feels bad and makes people bitter. The good news is that the attrition rate in big organizations is pretty high and those people may have left and been replaced by new people who we can approach again. This turnover is also the bad news: people who have been stakeholders in the past may have moved on as well. 
 
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.

Agreed. I'd like to try to improve this situation in 2021.
 

It's clear what's happened in the past is a combination of luck and graciousness by both Frank and Even. 

Howard

Howard, you're so right. Not every industry enjoys a resource like GDAL. It's a special project run by uniquely dedicated people.

--
Sean Gillies

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Paul Harwood
In reply to this post by Carl Godkin-2
+1 and more to Carl and Howard

That said, having been inside a FAANG I can understand that the contortions that you have to go through just to get a "charity" payment approved in terms of proving probity especially post SOX are enormous. I tried to get a G-normous company to provide network support after the earthquake in Nepal. It took a 5 minute call to VP to get a 6-figure budget and 6 months to find a route to get the money or goods delivered! I was told at the time that the lead time for getting a new not-for-profit organisation approved was 2 - 5 years! And don't even think of trying to get a payment for services without a service description, PO and invoice from an approved supplier. It is just physically impossible. They have huge resources in developer time that they throw around at a moment's notices but exporting cash is impossible.

I don't know the solution. The usual solution is an existing large, US-based foundation that has existing dealings with the FAANGS that could act as a conduit (perfectly legally).

On Wed, 13 Jan 2021 at 23:08, Carl Godkin <[hidden email]> wrote:
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 <[hidden email]> wrote:


On Jan 13, 2021, at 4:28 PM, Nyall Dawson <[hidden email]> wrote:

On Thu, 14 Jan 2021 at 06:24, David Strip <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Gerald Nelson-3

How does linux development get funded?

 

Gerald C. Nelson

Professor Emeritus, UIUC

+1 217-390-7888 (cell)

+1 970-639-2079 (land line)

Skype: jerrynelson

http://bit.ly/1arho7d

 

From: gdal-dev <[hidden email]> on behalf of Paul Harwood <[hidden email]>
Date: Wednesday, January 13, 2021 at 4:47 PM
To: Carl Godkin <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?

 

+1 and more to Carl and Howard

That said, having been inside a FAANG I can understand that the contortions that you have to go through just to get a "charity" payment approved in terms of proving probity especially post SOX are enormous. I tried to get a G-normous company to provide network support after the earthquake in Nepal. It took a 5 minute call to VP to get a 6-figure budget and 6 months to find a route to get the money or goods delivered! I was told at the time that the lead time for getting a new not-for-profit organisation approved was 2 - 5 years! And don't even think of trying to get a payment for services without a service description, PO and invoice from an approved supplier. It is just physically impossible. They have huge resources in developer time that they throw around at a moment's notices but exporting cash is impossible.

I don't know the solution. The usual solution is an existing large, US-based foundation that has existing dealings with the FAANGS that could act as a conduit (perfectly legally).

 

On Wed, 13 Jan 2021 at 23:08, Carl Godkin <[hidden email]> wrote:

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 <[hidden email]> wrote:

 



On Jan 13, 2021, at 4:28 PM, Nyall Dawson <[hidden email]> wrote:

 

On Thu, 14 Jan 2021 at 06:24, David Strip <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

David Strip-2
In reply to this post by Howard Butler-3
On 1/13/2021 3:58 PM, Howard Butler wrote:
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.
gdal wouldn't be the first project to change it's license, though I really don't know enough about the consequences others have faced for doing so.  Even the revered GPL is a moving target.
If the alternative is a burned out lead developer/maintainer and a dead project, that's not a desirable outcome either.

I'm not sure I agree that changing the license would create confusion and erode trust. Assuming that we (whoever "we" are) actually have the legal right to change the license, let's play a hypothetical.
The new license maintains fees from two classes of users:
1. Anyone incorporating gdal into a product that is
     a. not completely open source,  and
    b. charges a license fee (perpetual or subscription), and
    c. has more than x active licenses (x = 500? 1000?)
2. Any for-profit organization utilizing gdal in-house for data analysis, conversion, on-line services,  etc, in excess of x CPU hours per year (where y = 1000? 5000?...)
3. Any organization that uses gdal indirectly through a free, open source product (eg, QGIS) or a licensed product covered under 1) above is exempt from 1) and 2).

(Standard caveat - I'm not a lawyer and I'm not proposing this is the actual language of the license. It is intended as a discussion of how we might describe firms who are obligated to pay a license fee. I have deliberately not suggested an actual fee. The number of licensees will be small and I expect each license will be negotiated separately to suit the specific case.)

I don't think I need to name names - you know who the big players are in categories 1 and 2. Only two in category 1 and none in category 2 stepped up with a large (relative to the ask) commitment in the previous barn raising.

By selecting appropriate values for x and y the net result will be a very small number of large (and mostly extremely profitable)  firms are covered by the paid license category and they are easily identified. The value they derive from gdal far exceeds whatever might be asked of them to support one (or even several) full-time developers among themselves.

 Equally, the vast majority of users will have no question that they continue to operate in the free range. Given that this whole thing started with a suggestion that the only way to make users aware of deprecation of obsolete drivers was to make the drivers stop working, how many users will even be aware of a license change?

For the very few companies right at the boundary, it's not like the gdal license gods are going to audit to see if they have  x + 1 or x - 1 active licenses. At some point they will big enough that either they will voluntarily recognize their obligation or someone will call them out on it. It's not like gdal will have legion of lawyers chasing after folks any more than we currently chase those who fail to meet their obligations under the existing license.


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.
I don't see how another one-off barn-raising is a sustainable solution. I looked over the list and none of the companies (and I'm sure it's plural) "running 100,000,000 of CPU hours" contributed last time around. Even if that were to change, how often do you want to go around with your beggar's bowl asking for alms? Unless faced with a license that legally obligates them to contribute, history tells us they will not contribute anything near their fair share (or anything at all, for that matter).

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.
Absolutely on the mark. Funding has to be provided directly for on-going maintenance. It can't be scraped from a tax on new features. Regardless of whether the structure is a foundation or something else, the compelling issue is whether gdal will survive on voluntary contributions (and all the effort it takes to scrape those together). It hasn't worked in the past. Why will the future be different?


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Greg Troxel-2
In reply to this post by Paul Harwood

Paul Harwood <[hidden email]> writes:

> I don't know the solution. The usual solution is an existing large,
> US-based foundation that has existing dealings with the FAANGS that could
> act as a conduit (perfectly legally).

I'd like to thank Howard for speaking so clearly.

One of the really broken things is that big companies seem to have a
hard time making a donation to an open source project.  Yet they can pay
for proprietary software licenses with no effort.  So I wonder if
selling some kind of "gold support contract", would be viable, where all
that they get is to put the gold label on issues on the tracker, but
then it's a "support contract" and thus easy like a license, vs a
"donation".

I don't buy the notion that Sarbanes-Oxley makes this hard.  I think
that's just an excuse, based on my experience.


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (199 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Greg Troxel-2
In reply to this post by David Strip-2

David Strip <[hidden email]> writes:

>       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.

Strongly agreed.

>     gdal wouldn't be the first project to change it's license, though I
>     really don't know enough about the consequences others have faced
>     for doing so.  Even the revered GPL is a moving target.
>     If the alternative is a burned out lead developer/maintainer and a
>     dead project, that's not a desirable outcome either.

My impression is that every project that has tried to play games with
open source licenses has basically been a one-company project, and that
this has led to shunning.

>     I'm not sure I agree that changing the license would create
>     confusion and erode trust. Assuming that we (whoever "we" are)
>     actually have the legal right to change the license, let's play a
>     hypothetical.

The only projects that can arbitrarily change license are those in which

  The copyright is held my one company or a small number of people.
  This is why projects that pretend to be open source and ask for
  assignment of rights to a company are problematic.

  There are a small number of contributors who would agree.

  Projects that are e.g BSD licensed that want to move to GPL.  The old
  code remains, but the new code has a copyleft.

>     The new license maintains fees from two classes of users:
>     1. Anyone incorporating gdal into a product that is
>          a. not completely open source,  and
>         b. charges a license fee (perpetual or subscription), and
>         c. has more than x active licenses (x = 500? 1000?)
>     2. Any for-profit organization utilizing gdal in-house for data
>     analysis, conversion, on-line services,  etc, in excess of x CPU
>     hours per year (where y = 1000? 5000?...)
>     3. Any organization that uses gdal indirectly through a free, open
>     source product (eg, QGIS) or a licensed product covered under 1)
>     above is exempt from 1) and 2).
That's obviously no longer open source.

>     I don't think I need to name names - you know who the big players
>     are in categories 1 and 2. Only two in category 1 and none in
>     category 2 stepped up with a large (relative to the ask) commitment
>     in the previous barn raising.

I think you should name names.  It's not helpful to pretend we shouldn't.

>      Equally, the vast majority of users will have no question that they
>     continue to operate in the free range. Given that this whole thing
>     started with a suggestion that the only way to make users aware of
>     deprecation of obsolete drivers was to make the drivers stop
>     working, how many users will even be aware of a license change?

This will cause binary gdal packages, and everything that depends on
them, to get kicked out of first-class status or dropped from many
packaging systems.



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (199 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Ari Jolma-2
In reply to this post by Daniel Morissette
Thank you Howard, Daniel, Jukka, and others.

When I google for qgis I get its page and six sub pages in the way
Google does it. One of those is "Donations". When I do the same for
GDAL, there's no such page. I guess the first and practical thing to do
would be to make regular donations possible. The second thing would be
to advocate companies/people to make donations without strings attached.
That's already much in the domain of OSGeo, but the first thing is quite
much in the project's domain.

Best regards,

Ari


Daniel Morissette kirjoitti 13.1.2021 klo 21.11:

> Thank you Howard for a great analysis and for pointing out the key
> problems.
>
> Personally I think the top two problems are:
>
> 1- Bus number: we need to find a way to increase the number of active
> maintainers to ensure the viability and velocity of the project
>
> 2- Sustainable revenue stream for maintenance activities: as you
> explained, it is relatively easy to fund features, but profitable
> companies selling software or services that use GDAL need to realize
> that it would be an investment for them to contribute even just a
> fraction of 1% of their sales in "non-string-attached funding" to
> support non-sexy stuff such as release management, bug fixes, security
> fixes, dependency upgrades, packaging, docs, etc... not only in GDAL,
> but in the top-5 open source components that they rely on.
>
> The QGIS approach to managing funding is an option, but it's not the
> only one. I would tend to go for a more decentralized approach to
> reduce the risk for the project with a single entity supporting it.
>
> I step up to work with you Howard toward improving the situation.
> (Actually I had already written personally to Even to discuss some
> options before seeing your reply)
>
> Daniel
>
>
>
> On 2021-01-13 12:33, Howard Butler wrote:
>>
>>> Is there something fundamentally wrong with the current GDAL?
>>
>> The project's history is one person doing most of the work. This
>> person eventually burns out.
>>
>> Here's a table of the top five lifetime commits to the repository as
>> of December 2020.
>>
>> Even Rouault – 19,838
>> Frank Warmerdam – 11,503
>> Kurt Schwehr – 3,403
>> Andrey Kiselev – 1,320
>> Howard Butler – 768
>>
>> The reason why this person burns out is they are actually doing
>> *three* jobs, not one. Three, you say?
>>
>> First is the actual maintainer job. You're the clearinghouse for
>> bugs, the primary authority on the mailing list, the first respondent
>> in the bug tracker, and the one that organizes and cuts the software
>> release. When we think of the maintainer for the GDAL project, this
>> is what we think of. No one organization will pay for just this job.
>>
>> This means you need a revenue stream to make it maintenance your full
>> time gig. That's easy enough, just get paid for working on GDAL,
>> right? Well sure, but people don't want to pay for you to fix bugs
>> that users vaguely provide in the mailing list. They want to pay for
>> functionality they need to add to their software. So you are in a
>> spot – you have to *add* more to the software to earn revenue. For
>> GDAL, adding more means more drivers and more capabilities for those
>> drivers (CPL, VSICloud, etc). This creates more bugs and maintenance
>> load that the original directed funder supports for only a little
>> while. This second job is in conflict with the first and the
>> dissonance amplifies as time goes one.
>>
>> The third job is you have to solicit work through the contacts you've
>> built up to keep the revenue hopper full. Invoicing, statements of
>> work, negotiation, telecons, and the usual business stuff. People see
>> you as cheap because you're "open source", and pressure you on price,
>> scope, and completion time. You eventually orient about a small cadre
>> of repeat clients with strong trust relationships.
>>
>> How can this be fixed?
>>
>> 1) Burn through the current maintainer and hope another one comes
>> along. The users of the GDAL project simply got lucky that Even
>> picked up the torch after Frank moved on. Maybe that happens again on
>> the next iteration.
>>
>> 2) Refactor the software so that more maintainers can participate.
>> That's been our current discussion, which doesn't seem to be
>> converging on any solutions.
>>
>> 3) Provide a revenue stream so the maintainer only has to do the
>> maintenance job, and not the other two jobs that are in conflict with
>> the project's maintenance. This person should be paid like the FAANG
>> senior engineer that's currently taking GDAL and using it to add some
>> geo widget to their software.
>>
>> OSGeo was supposed to be the answer to #3, but in 15 years of
>> existence it has shown it is not and never will be. Maybe it is time
>> to start a GDAL foundation ala QGIS and others and direct corporate
>> benefactors to fund it directly. Those benefactors would have to
>> pledge significant resources to at least get to the level of a FAANG
>> senior engineer as a start.
>>
>> Howard
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

lhomme.xavier
Hello all
 The question of maintaining the old drivers raises a whole bunch of questions: how to finance the technical debt, how to involve more developers in this project, how to promote it, ... GDAL is an OSGeo project. Shouldn't these questions be addressed by OSGeo which should help in the distribution of funds, help in piloting this project...? Maybe OSGeo could get closer to an organization like OGC with members funding projects, initiative projets, testbed ...

Best regards
xlhomme

Le jeu. 14 janv. 2021 à 07:06, Ari Jolma <[hidden email]> a écrit :
Thank you Howard, Daniel, Jukka, and others.

When I google for qgis I get its page and six sub pages in the way
Google does it. One of those is "Donations". When I do the same for
GDAL, there's no such page. I guess the first and practical thing to do
would be to make regular donations possible. The second thing would be
to advocate companies/people to make donations without strings attached.
That's already much in the domain of OSGeo, but the first thing is quite
much in the project's domain.

Best regards,

Ari


Daniel Morissette kirjoitti 13.1.2021 klo 21.11:
> Thank you Howard for a great analysis and for pointing out the key
> problems.
>
> Personally I think the top two problems are:
>
> 1- Bus number: we need to find a way to increase the number of active
> maintainers to ensure the viability and velocity of the project
>
> 2- Sustainable revenue stream for maintenance activities: as you
> explained, it is relatively easy to fund features, but profitable
> companies selling software or services that use GDAL need to realize
> that it would be an investment for them to contribute even just a
> fraction of 1% of their sales in "non-string-attached funding" to
> support non-sexy stuff such as release management, bug fixes, security
> fixes, dependency upgrades, packaging, docs, etc... not only in GDAL,
> but in the top-5 open source components that they rely on.
>
> The QGIS approach to managing funding is an option, but it's not the
> only one. I would tend to go for a more decentralized approach to
> reduce the risk for the project with a single entity supporting it.
>
> I step up to work with you Howard toward improving the situation.
> (Actually I had already written personally to Even to discuss some
> options before seeing your reply)
>
> Daniel
>
>
>
> On 2021-01-13 12:33, Howard Butler wrote:
>>
>>> Is there something fundamentally wrong with the current GDAL?
>>
>> The project's history is one person doing most of the work. This
>> person eventually burns out.
>>
>> Here's a table of the top five lifetime commits to the repository as
>> of December 2020.
>>
>> Even Rouault – 19,838
>> Frank Warmerdam – 11,503
>> Kurt Schwehr – 3,403
>> Andrey Kiselev – 1,320
>> Howard Butler – 768
>>
>> The reason why this person burns out is they are actually doing
>> *three* jobs, not one. Three, you say?
>>
>> First is the actual maintainer job. You're the clearinghouse for
>> bugs, the primary authority on the mailing list, the first respondent
>> in the bug tracker, and the one that organizes and cuts the software
>> release. When we think of the maintainer for the GDAL project, this
>> is what we think of. No one organization will pay for just this job.
>>
>> This means you need a revenue stream to make it maintenance your full
>> time gig. That's easy enough, just get paid for working on GDAL,
>> right? Well sure, but people don't want to pay for you to fix bugs
>> that users vaguely provide in the mailing list. They want to pay for
>> functionality they need to add to their software. So you are in a
>> spot – you have to *add* more to the software to earn revenue. For
>> GDAL, adding more means more drivers and more capabilities for those
>> drivers (CPL, VSICloud, etc). This creates more bugs and maintenance
>> load that the original directed funder supports for only a little
>> while. This second job is in conflict with the first and the
>> dissonance amplifies as time goes one.
>>
>> The third job is you have to solicit work through the contacts you've
>> built up to keep the revenue hopper full. Invoicing, statements of
>> work, negotiation, telecons, and the usual business stuff. People see
>> you as cheap because you're "open source", and pressure you on price,
>> scope, and completion time. You eventually orient about a small cadre
>> of repeat clients with strong trust relationships.
>>
>> How can this be fixed?
>>
>> 1) Burn through the current maintainer and hope another one comes
>> along. The users of the GDAL project simply got lucky that Even
>> picked up the torch after Frank moved on. Maybe that happens again on
>> the next iteration.
>>
>> 2) Refactor the software so that more maintainers can participate.
>> That's been our current discussion, which doesn't seem to be
>> converging on any solutions.
>>
>> 3) Provide a revenue stream so the maintainer only has to do the
>> maintenance job, and not the other two jobs that are in conflict with
>> the project's maintenance. This person should be paid like the FAANG
>> senior engineer that's currently taking GDAL and using it to add some
>> geo widget to their software.
>>
>> OSGeo was supposed to be the answer to #3, but in 15 years of
>> existence it has shown it is not and never will be. Maybe it is time
>> to start a GDAL foundation ala QGIS and others and direct corporate
>> benefactors to fund it directly. Those benefactors would have to
>> pledge significant resources to at least get to the level of a FAANG
>> senior engineer as a start.
>>
>> Howard
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Driver maintenance - long-term solution ?

Angelos Tzotsos
In reply to this post by Howard Butler-3
Perhaps we could ask some of these organizations to sponsor GDAL through https://github.com/sponsors/OSGeo which is a recurring sponsorship ?

Angelos


On 1/14/21 12:58 AM, Howard Butler wrote:

On Jan 13, 2021, at 4:28 PM, Nyall Dawson [hidden email] wrote:

On Thu, 14 Jan 2021 at 06:24, David Strip [hidden email] 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 <http://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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Angelos Tzotsos, PhD
President
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

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

Paul Harwood
In reply to this post by Greg Troxel-2
oops - forgot to reply-all :(

Just to add one example though. I am sure you will find that all FAANGs have "modern slavery" regulations that mean that anyone they pay has to able to prove that they are not exploiting workers. I would hope that you would agree that they SHOULD have modern slavery regulations.

How exactly does open-source software prove that? I am sure there are established mechanisms but do you know them ... ?

---------- Forwarded message ---------
From: Paul Harwood <[hidden email]>
Date: Thu, 14 Jan 2021 at 09:15
Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?
To: Greg Troxel <[hidden email]>




One of the really broken things is that big companies seem to have a
hard time making a donation to an open source project.  Yet they can pay
for proprietary software licenses with no effort.  So I wonder if
selling some kind of "gold support contract", would be viable, where all
that they get is to put the gold label on issues on the tracker, but
then it's a "support contract" and thus easy like a license, vs a
"donation".

I don't buy the notion that Sarbanes-Oxley makes this hard.  I think
that's just an excuse, based on my experience.

IANAL

I don't think it matters whether it is really SOX or just the way these companies have implemented SOX, the fact is that the risk management process that came out of it make it a lot of work for the individuals in those companies to make this type of payment. That is not a justification for anything, but we should recognise that the individual in those companies who wants to support us is not going to get an easy life!

You can see from the lawyers and accountants point of view that a product with a scope of work, a PO and an invoice is a much easier paper trail to follow than a donation. It is difficult to prove that a donation is not patronage. In some countries (possibly most, I don't know) you cannot call it charity even if it is not-for-profit because you get something back - the software. You cannot be seen to get any material return from an organisation you make a charitable donation to. So it is a gratis payment for no services to an organization that also just happens to provide you software for free. Say that to lawyer and they will probably ask you exactly how you are different from the mafia :)

I am not saying that it is not possible - I am sure there are very good ways to do this. I am just saying that you have to acknowledge it is hard. You cannot just tell them they are wrong and that they should just give out some money. Most of the people you are talking to will probably agree with you but also forget you in about 5 minutes and go and do something that is possible.

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
12