[gdal-dev] Considering drivers removal ?

[Howard Butler]

> On Jan 12, 2021, at 8:48 AM, Jonathan Gale <jgale at mathworks.com> wrote:
> 
> Hi,
>  
> Looking at the list, we use/support SDTS Raster import. As a US government format with the use case mentioned below, I’d prefer to not see the format removed from the software.  We have some evidence that the format is still used by some of our users.

It would be helpful for Mathworks to provide the GDAL project a list of "used" formats in its software. GDAL doesn't get that recon, and it can't put phone home capability into the software to get it either.

>  The users of the software I help develop and maintain expect a high level of compatibility across releases.  A commonly discussed use case involves rerunning the same code with the same data across many years to ensure reproducibility of results.  While we see the need to keep code maintainable, it feels important to consider this use case. 

So the open source project your commercial software product depends upon is supposed to worry about forever version compatibility to protect your product? You may not have said it this way, but this is what I hear when I read this statement. It is especially frustrating to hear given the many commercial entities like Mathworks that have leveraged GDAL for years without providing non-targeted financial and developer resources back to the project to carry this kind of maintenance burden. 

The community doesn't maintain GDAL – Even Rouault does (right now, just like Frank Warmerdam did before him). The community doesn't really share the burden, but it does share its rewards (1000 line NEWS posts of updates to the project every release). Even is now searching for ways to make it more maintainable given that the resources to sustain the current trajectory have not materialized. This includes culling drivers that merely add burden and evolving old stuff where appropriate (code, configuration, APIs).  It isn't on us to say whether something is or isn't a burden either – we need to step into the breach if we need to keep something around. 

A problem with GDAL is the breach is a 1 million line behemoth with homegrown test suites, build setups, software layout, and type system. It is not a comfortable project to make casual contributions because it requires a lot of investment to get up to speed. You end up having to carry the rock of 20 years of software (mis)behavior as you do it. For anything other than adding another driver, this burden ends up being too great. So while we want more maintainers (working free to us!), the software itself makes it very difficult for them to grow into the role. Attempts to relax the dough to allow that to happen are met with, well, this mailing list thread.  
 
> Not specific to the software I work on, I think of GDAL as a “swiss army knife” of geospatial format support.  It is the FOSS way to access many formats both new and old.  I do wonder whether alternatives available should be considered when evaluating a given driver for removal.  It would be unfortunate if there was no way to read a format anymore with available software.

The old versions are still available, but I understand as a commercial product, you want BOTH the maintenance and bug fixing of existing software plus all of the goodie features of a new release. 

> Overall, we like the idea of introducing a process for this.  Thinking about next steps, it is important to consider what the criterion should be as Even mentioned.  How many users?  Who are these users?  How do we estimate the downstream impact on users who don’t know that their format is being considered for removal?  As others have mentioned, how does maintainability factor in?  I hope that if there was a process to do this, that it would be codified and visible.

The only question that matters here is "Who is going to maintain it?" and if the answer to that is "no one", it should be removed. There doesn't need to be any meetings because the only criteria that matters is if someone is willing to maintain it. We should provide the list of drivers and assign the GitHub handles that step forward to be responsible for each. If obscure government one-offs formats have an audience of downtrodden government users forced to use them, they need to put their handle in and take ownership. They then need to find the time, money, or attention to carry things forward. 

Howard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210112/3031501f/attachment-0001.html>