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

[Howard Butler]

> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210113/32debc2e/attachment.html>