[gdal-dev] 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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 


-- 
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201