> but from my point of view supporting a lot of formats is part of GDAL's
> success,
GDAL is a 22 year old software project. It's not just that GDAL supports lots
of formats. It is also that the code supporting all of those formats is
meticulously maintained, and it maintains *good* support for all of those
formats. The bulk of that meticulous maintenance has not been evenly carried by
the individuals, organizations, and companies that have been enjoying the
benefits from it. GDAL maintenance as currently happen(ed) is unsustainable in
all of the ways you read about in handwringing think pieces on the internet
about open source software projects.
> so maybe the real focus should be on implementing a plugin mechanism that
> would allow driver development independently from core GDAL.
As I see it, the project has three potential futures:
1) Continue the current architectural and niche trajectory. A one-stop-shop for
geospatial formats that is conveniently distributed in all relevant platforms.
2) Split GDAL/OGR core from the drivers so that each can evolve and be
maintained at their own pace according to the attention they can attract.
3) Let GDAL rot as-is with low wattage community maintenance and exist as a
zombie gut pile of useful code that organizations continue to pull from and
incorporate into their own software.
I think we as a community want status quo – #1 – all of the goodness that GDAL
provides by a complete implementation of the geospatial format universe all in
one spot. As should be becoming clear by these threads, this scenario is not
likely to continue due to the three jobs problem [1] I described earlier in the
thread. Our options to maintain this status quo is for the community to provide
the revenue stream for someone to do just the maintainer job, effectively split
the maintenance activities, or find another Even that wants three jobs :)
The second scenario has the potential to make it easier to share the
maintenance burden, but it cleaves off what many see as GDAL's best feature –
universality – by making support for specific formats be a packager's or a
user's burden. It would limit the GDAL platform leverage that vendors currently
get by injecting support for their proprietary SDKs for the project to carry,
and the impact and station of GDAL is likely to be reduced by this approach.
Maybe that could be a good thing.
The third scenario is a common one. Organizations with the need and resources
to internally spend will continue to maintain GDAL in their (closed) codebases.
The software-based interoperability that GDAL provides the industry will
diminish, and the existing tree will reach a kind of stasis with open source
distributors until the bugs accumulate in frequency and scope to cause it to
get dropped.
Howard
[1] https://lists.osgeo.org/pipermail/gdal-dev/2021-January/053302.html
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
