<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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. <div><br></div><div>That said figuring out the long term funding for the project core is critical. </div><div><br></div><div>Unfortunately I’m only in a position to offer an opinion and not much more so feel free to ignore it. </div><div><br></div><div>Best regards,</div><div>-Steve W<br><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Jan 27, 2021, at 12:28 PM, Howard Butler <howard@hobu.co> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><blockquote type="cite" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">but from my point of view supporting a lot of formats is part of GDAL's success, </span></blockquote><div class=""><br class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">GDAL is a 22 year old software project. </span>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.</div><div class=""><br class=""></div><blockquote type="cite" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">so maybe the real focus should be on implementing a plugin mechanism that would allow driver development independently from core GDAL. </span></blockquote><div class=""><br class=""></div><div class="">As I see it, the project has three potential futures:</div><div class=""><br class=""></div><div class="">1) Continue the current architectural and niche trajectory. A one-stop-shop for geospatial formats that is conveniently distributed in all relevant platforms.</div>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.<div class="">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. </div><div class=""><br class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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 :)</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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. </span></div><div class=""><br class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Howard</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">[1] </span><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><a href="https://lists.osgeo.org/pipermail/gdal-dev/2021-January/053302.html" class="">https://lists.osgeo.org/pipermail/gdal-dev/2021-January/053302.html</a></span></font></div><span>_______________________________________________</span><br><span>gdal-dev mailing list</span><br><span>gdal-dev@lists.osgeo.org</span><br><span>https://lists.osgeo.org/mailman/listinfo/gdal-dev</span><br></div></blockquote></div></body></html>