<div dir="ltr">Hi Rainer, <div>Thanks for working on this and all of your work on SAGA. I am considering taking over the plugin because I use and teach with SAGA in QGIS and it works for me in the current state. </div><div>If I wanted to ask questions or get updates on potentially breaking changes would I do that on the sourceforge forum? </div><div>I did try using PySAGA found it to be much slower but I don't think I was using the pre file conversion the the current plugin uses or I wasn't batching my calls correctly so I would be interested to find out the best way to set this up in the future. </div><div>the repository is here- <a href="https://github.com/baswein/qgis-processing-saga-nextgen">https://github.com/baswein/qgis-processing-saga-nextgen</a></div><div>Thanks again. </div><div>-Bas</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 1, 2026 at 2:24 PM Rainer Hurling via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear QGIS developers,<br>
I had promised to get back to you after a meeting with our SAGA <br>
dev-team. I would like to do so here.<br>
<br>
Am 25.05.26 um 18:25 schrieb Rainer Hurling via QGIS-Developer:<br>
> Dear QGIS devs,<br>
> I am writing to you on behalf of the small group of SAGA GIS developers.<br>
> This thread has raised several points and perspectives that are of great <br>
> interest to us, and we would like to share the SAGA team’s perspective <br>
> on them.<br>
> <br>
> However, before we contribute here, we would like to discuss this at our <br>
> regular developer meeting next Friday (May 29). We have already added <br>
> the topic to the agenda :)<br>
> After that, we will post here in the thread and try to outline our options.<br>
> <br>
> @Nyall: Could you please make the “SAGA Processing Nextgen” plugin, <br>
> which is currently set to “private”, public again for a while? I’d like <br>
> to fork it, thanks!<br>
> <br>
> Best wishes,<br>
> Rainer  (FreeBSD ports committer)<br>
<br>
<br>
Since this thread concerns the “Processing Saga NextGen Provider” <br>
plugin, it should be noted up front that this is a QGIS plugin developed <br>
by a QGIS developer. The SAGA team was never involved in its development.<br>
<br>
We discussed the following in our SAGA meeting:<br>
<br>
- Basically, we (at SAGA) have no interest in maintaining the existing <br>
plugin, further developing it, or even developing a new, more <br>
comprehensive SAGA plugin for QGIS.<br>
<br>
- If there is interest within the QGIS community in developing a more <br>
comprehensive plugin for integrating SAGA, we recommend not building on <br>
the SAGA command-line tool ‘saga_cmd’ but instead using PySAGA (or the <br>
C++ API). This would allow the respective functionalities and parameters <br>
of all non-interactive SAGA tools to be used directly and <br>
comprehensively. It would also allow in-memory passing of datasets, i.e. <br>
no temporary files would need to be written.<br>
<br>
- Converting all data types on a 1:1 basis is likely to remain a <br>
challenge. There are data types in SAGA that do not exist in QGIS.<br>
<br>
- Overall, we are positive about the integration of SAGA in QGIS, but we <br>
think such a project needs a sustainable approach. If the QGIS community <br>
wishes to improve or update the integration of SAGA with QGIS, the SAGA <br>
team is happy to provide information and advice if requested. We would <br>
also be happy to establish or point to communication channels so that <br>
the community can stay informed about new SAGA versions and upcoming <br>
changes.<br>
<br>
<br>
A personal note on the “Processing Saga NextGen Provider” plugin: Since <br>
I am the maintainer (rhurlin@FreeBSD.org) of both the SAGA GIS port [1] <br>
and the QGIS port [2] for FreeBSD, I decided out of curiosity to copy <br>
the SAGA NextGen Provider plugin from a QGIS 3 installation to a QGIS 4 <br>
installation and then run the ‘scan_qt6_compat’ v1.2 plugin by François <br>
Thevand on the SAGA plugin in QGIS 4. This allowed the SAGA plugin to be <br>
converted to Qt6 and QGIS 4 fully automatically and seemingly without <br>
errors, and it can now be used in QGIS 4 as usual. Perhaps this is a way <br>
for the QGIS community to continue working with this plugin for the time <br>
being?<br>
<br>
[1] <a href="https://www.freshports.org/math/saga" rel="noreferrer" target="_blank">https://www.freshports.org/math/saga</a><br>
[2] <a href="https://www.freshports.org/graphics/qgis" rel="noreferrer" target="_blank">https://www.freshports.org/graphics/qgis</a> and<br>
     <a href="https://www.freshports.org/graphics/qgis-ltr" rel="noreferrer" target="_blank">https://www.freshports.org/graphics/qgis-ltr</a><br>
<br>
Best regards,<br>
Rainer<br>
<br>
<br>
> Am 22.05.26 um 01:55 schrieb Nyall Dawson via QGIS-Developer:<br>
>> On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer <qgis- <br>
>> <a href="mailto:developer@lists.osgeo.org" target="_blank">developer@lists.osgeo.org</a> <mailto:<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.org</a>>> wrote:<br>
>><br>
>>  > I’m writing to the dev list because I think this issue is of interest.<br>
>>  ><br>
>>  > For the past few days, the SAGA Next plugin—which allows you to use <br>
>> SAGA GIS modules within QGIS Processing—has been unavailable.<br>
>><br>
>> Thanks for kicking off this discussion -- I've been waiting for <br>
>> someone to raise it 😁🍿<br>
>><br>
>> To explain the situation:<br>
>><br>
>> I've been "maintaining" that plugin for years. That's an over- <br>
>> exaggeration... it hasn't received any love from me beyond reviewing a <br>
>> pull request once every couple of years. I initially forked it (SAGA <br>
>> NextGen) from the core SAGA plugin back in 2019 to help solve issues <br>
>> with SAGA availability of LTR releases and broken stable API. Then in <br>
>> 2019 <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230</a> <br>
>> <<a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230</a>> <br>
>> followed, when the built-in SAGA plugin was removed and it went from <br>
>> being an out-of-the-box, "<a href="http://qgis.org" rel="noreferrer" target="_blank">qgis.org</a> <<a href="http://qgis.org" rel="noreferrer" target="_blank">http://qgis.org</a>> maintained" <br>
>> plugin to relying on the third party SAGA NextGen "community <br>
>> maintained" plugin. That's 100% because it was concluded by all the <br>
>> developers responsible for that code that it wasn't up to the quality <br>
>> standards of the rest of QGIS.<br>
>><br>
>> It was always a fragile mess of a plugin. Part of that was because of <br>
>> the difficulties associated with SAGA versioning, part of that was <br>
>> because it was initially forked from old python code that no-one had <br>
>> ever modernised. To say it was held together with chewing gum would be <br>
>> a lie... it was held together with some soggy wet toilet paper at <br>
>> best! 😆 This really bugged me. I'd see constant user frustration <br>
>> because it never worked well, and IMO this user frustration was <br>
>> harming the reputation of QGIS itself. It didn't help that I'd keep <br>
>> reading blogs/guides/tutorials where people were recommending using it <br>
>> for operations where QGIS native tools are SOOOO much better (eg <br>
>> vector operations like buffering).<br>
>><br>
>> It was never my desire to become the maintainer of the plugin and put <br>
>> in the work required to bring it up to the quality standard I hold to, <br>
>> rather, I offered it on an initially voluntary basis to fix immediate <br>
>> issues I saw users were experiencing and with the hope that making it <br>
>> a third party plugin would help grow a healthy community that would <br>
>> take it over.<br>
>><br>
>> That never happened... Instead it was just another burden that I <br>
>> carried for everyone, with the associated lack of thanks and lack of <br>
>> any recognition beyond angry emails when it didn't work. 🤷. Ah well, <br>
>> that's just life as a QGIS developer, we all deal with that, and I'm <br>
>> thick- skinned enough to handle it!<br>
>><br>
>> At least, I thought so. Then the AI apocalypse hit in 2026.<br>
>><br>
>> As a response to my frustration with the lack of support the user <br>
>> community is giving to open-source developers during this INCREDIBLY <br>
>> challenging time, I decided to close off a bunch of my public <br>
>> repositories. Because, hey, I don't want to directly train the <br>
>> technologies that will likely destroy the whole economics behind open- <br>
>> source software development. So I closed off repositories for things <br>
>> I'd voluntarily made public, including dropping any QGIS plugin that I <br>
>> wasn't directly using myself anymore, and that wasn't funded or in use <br>
>> by my customers (or where a better native tool now exists). And that <br>
>> included the SAGA NextGen plugin. I have no use for it, and none of my <br>
>> customers use it, and it's a PITA to "maintain".<br>
>><br>
>> I knew that by doing so I'd be stirring up trouble, and honestly, that <br>
>> was partly my intention! I wanted to force a discussion about this, <br>
>> and raise widespread attention to the issues that would otherwise go <br>
>> unnoticed. It's the SAGA plugin today, but tomorrow it could easily be <br>
>> QGIS itself, or GDAL, or PostGIS, or PDAL, or ... 😱<br>
>><br>
>> My personal preference would be that we continue to port useful tools <br>
>> from SAGA to native QGIS versions of these tools. I've done this in <br>
>> the past (see <a href="https://github.com/qgis/QGIS/pull/53794" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/pull/53794</a> <https:// <br>
>> <a href="http://github.com/" rel="noreferrer" target="_blank">github.com/</a> qgis/QGIS/pull/53794>, <a href="https://github.com/qgis/QGIS/" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/</a> <br>
>> pull/61722 <https:// <a href="http://github.com/qgis/QGIS/pull/61722" rel="noreferrer" target="_blank">github.com/qgis/QGIS/pull/61722</a>>) for tools that <br>
>> I need myself, or that my customers rely on, and the QGIS native tools <br>
>> are so much better (***FOR QGIS USERS***) then calling out to the SAGA <br>
>> versions. They have full format support for all the data sources QGIS <br>
>> supports, they work with massive rasters without memory issues, and <br>
>> they are much faster as they don't require data conversion to <br>
>> intermediate formats. And on top of that, they "just work" everywhere <br>
>> QGIS works -- there's no fussing around with SAGA version <br>
>> compatibility, and no security risks with python code shelling out to <br>
>> run random batch files.<br>
>><br>
>> (Please understand that I'm not insulting the SAGA developers or their <br>
>> versions of these tools here... in my experience the SAGA developer's <br>
>> logic is great, the code is well written and the algorithms themselves <br>
>> are well designed. It's a testament to the SAGA developers how easy it <br>
>> is to port the tools to QGIS, they are very readable and well <br>
>> documented. My point is that we offer a better experience to **QGIS** <br>
>> users by porting the tools to native equivalents using QGIS API <br>
>> directly).<br>
>><br>
>> If anyone has particular SAGA tools they rely on for their work, then <br>
>> please reach out and I'll let you know how much it would cost to <br>
>> sponsor a port of that tool.<br>
>><br>
>> Finally, please note that I didn't delete the plugin repository, I <br>
>> just made it private instead of public. I'm happy to temporarily make <br>
>> it public again if someone wants to fork it, but after they do that <br>
>> I'll then permanently erase my repo. If someone wants to do this then <br>
>> let me know and I'll re-open temporarily.<br>
>><br>
>> Nyall<br>
>><br>
>><br>
>>  ><br>
>>  > According to reports in the QGIS community’s Telegram group, <br>
>> maintaining this plugin is becoming increasingly difficult due to <br>
>> developments in the SAGA project, which can cause the plugin to stop <br>
>> working.<br>
>>  ><br>
>>  > I recall that until a couple of years ago, SAGA was, like GRASS, a <br>
>> resource installed directly within QGIS, but then, precisely because <br>
>> of the difficulty in keeping up with SAGA’s developments, it was <br>
>> decided to treat SAGA as a third-party resource accessible via plugins.<br>
>>  ><br>
>>  > I believe it is right that this important resource should not be <br>
>> maintained on a voluntary basis by a single developer/user, but that <br>
>> it should be taken on by the community.<br>
>>  ><br>
>>  > Do you think it would be a good idea to propose to the Steering <br>
>> Group that its maintenance be taken on directly by the QGIS.org <br>
>> Foundation and that a certain sum (1000–2000 euros?) be set aside in <br>
>> the annual budget for its maintenance?<br>
>>  ><br>
>>  > Thank you<br>
>>  ><br>
>>  > stefano campus<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">___________________________<br><div dir="ltr"><span>Sebastian "Bas* " Gutwein</span></div><div><span><span>*rhymes with Josh <br></span></span></div><div><span><span><br></span></span></div>Regenerative Design Group<br>1 Chevalier Ave<br>Greenfield, Ma 01301<br>Web: <a href="http://regenerativedesigngroup.com" target="_blank">regenerativedesigngroup.com</a><br>(631) 241-1018<br><br><div dir="ltr"><i><span><span>Look close, think big, make change. </span></span></i></div><div dir="ltr"><span></span></div></div></div>