I think a 4th option is a hybrid approach of moving to a more modular plug-in architecture that allows the core more flexibility to evolve at the same time by moving to a more plug-in driver allows for more independent development, testing and release lets the community participation. This does stop the core from maintaining some of the drivers also. I don’t see value in maintaining obsolete drivers or drivers that only a few people use if it costs us a lot to maintain them.
That said figuring out the long term funding for the project core is critical. Unfortunately I’m only in a position to offer an opinion and not much more so feel free to ignore it. Best regards, -Steve W Sent from my iPhone > On Jan 27, 2021, at 12:28 PM, Howard Butler <how...@hobu.co> wrote: > > >> >> 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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
