[QGIS-Developer] SAGA GIS plugin maintenance

[Rainer Hurling]

Dear QGIS developers,
I had promised to get back to you after a meeting with our SAGA 
dev-team. I would like to do so here.

Am 25.05.26 um 18:25 schrieb Rainer Hurling via QGIS-Developer:
> Dear QGIS devs,
> I am writing to you on behalf of the small group of SAGA GIS developers.
> This thread has raised several points and perspectives that are of great 
> interest to us, and we would like to share the SAGA team’s perspective 
> on them.
> 
> However, before we contribute here, we would like to discuss this at our 
> regular developer meeting next Friday (May 29). We have already added 
> the topic to the agenda :)
> After that, we will post here in the thread and try to outline our options.
> 
> @Nyall: Could you please make the “SAGA Processing Nextgen” plugin, 
> which is currently set to “private”, public again for a while? I’d like 
> to fork it, thanks!
> 
> Best wishes,
> Rainer  (FreeBSD ports committer)


Since this thread concerns the “Processing Saga NextGen Provider” 
plugin, it should be noted up front that this is a QGIS plugin developed 
by a QGIS developer. The SAGA team was never involved in its development.

We discussed the following in our SAGA meeting:

- Basically, we (at SAGA) have no interest in maintaining the existing 
plugin, further developing it, or even developing a new, more 
comprehensive SAGA plugin for QGIS.

- If there is interest within the QGIS community in developing a more 
comprehensive plugin for integrating SAGA, we recommend not building on 
the SAGA command-line tool ‘saga_cmd’ but instead using PySAGA (or the 
C++ API). This would allow the respective functionalities and parameters 
of all non-interactive SAGA tools to be used directly and 
comprehensively. It would also allow in-memory passing of datasets, i.e. 
no temporary files would need to be written.

- Converting all data types on a 1:1 basis is likely to remain a 
challenge. There are data types in SAGA that do not exist in QGIS.

- Overall, we are positive about the integration of SAGA in QGIS, but we 
think such a project needs a sustainable approach. If the QGIS community 
wishes to improve or update the integration of SAGA with QGIS, the SAGA 
team is happy to provide information and advice if requested. We would 
also be happy to establish or point to communication channels so that 
the community can stay informed about new SAGA versions and upcoming 
changes.


A personal note on the “Processing Saga NextGen Provider” plugin: Since 
I am the maintainer (rhurlin at FreeBSD.org) of both the SAGA GIS port [1] 
and the QGIS port [2] for FreeBSD, I decided out of curiosity to copy 
the SAGA NextGen Provider plugin from a QGIS 3 installation to a QGIS 4 
installation and then run the ‘scan_qt6_compat’ v1.2 plugin by François 
Thevand on the SAGA plugin in QGIS 4. This allowed the SAGA plugin to be 
converted to Qt6 and QGIS 4 fully automatically and seemingly without 
errors, and it can now be used in QGIS 4 as usual. Perhaps this is a way 
for the QGIS community to continue working with this plugin for the time 
being?

[1] https://www.freshports.org/math/saga
[2] https://www.freshports.org/graphics/qgis and
     https://www.freshports.org/graphics/qgis-ltr

Best regards,
Rainer


> Am 22.05.26 um 01:55 schrieb Nyall Dawson via QGIS-Developer:
>> On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer <qgis- 
>> developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>> wrote:
>>
>>  > I’m writing to the dev list because I think this issue is of interest.
>>  >
>>  > For the past few days, the SAGA Next plugin—which allows you to use 
>> SAGA GIS modules within QGIS Processing—has been unavailable.
>>
>> Thanks for kicking off this discussion -- I've been waiting for 
>> someone to raise it 😁🍿
>>
>> To explain the situation:
>>
>> I've been "maintaining" that plugin for years. That's an over- 
>> exaggeration... it hasn't received any love from me beyond reviewing a 
>> pull request once every couple of years. I initially forked it (SAGA 
>> NextGen) from the core SAGA plugin back in 2019 to help solve issues 
>> with SAGA availability of LTR releases and broken stable API. Then in 
>> 2019 https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230 
>> <https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230> 
>> followed, when the built-in SAGA plugin was removed and it went from 
>> being an out-of-the-box, "qgis.org <http://qgis.org> maintained" 
>> plugin to relying on the third party SAGA NextGen "community 
>> maintained" plugin. That's 100% because it was concluded by all the 
>> developers responsible for that code that it wasn't up to the quality 
>> standards of the rest of QGIS.
>>
>> It was always a fragile mess of a plugin. Part of that was because of 
>> the difficulties associated with SAGA versioning, part of that was 
>> because it was initially forked from old python code that no-one had 
>> ever modernised. To say it was held together with chewing gum would be 
>> a lie... it was held together with some soggy wet toilet paper at 
>> best! 😆 This really bugged me. I'd see constant user frustration 
>> because it never worked well, and IMO this user frustration was 
>> harming the reputation of QGIS itself. It didn't help that I'd keep 
>> reading blogs/guides/tutorials where people were recommending using it 
>> for operations where QGIS native tools are SOOOO much better (eg 
>> vector operations like buffering).
>>
>> It was never my desire to become the maintainer of the plugin and put 
>> in the work required to bring it up to the quality standard I hold to, 
>> rather, I offered it on an initially voluntary basis to fix immediate 
>> issues I saw users were experiencing and with the hope that making it 
>> a third party plugin would help grow a healthy community that would 
>> take it over.
>>
>> That never happened... Instead it was just another burden that I 
>> carried for everyone, with the associated lack of thanks and lack of 
>> any recognition beyond angry emails when it didn't work. 🤷. Ah well, 
>> that's just life as a QGIS developer, we all deal with that, and I'm 
>> thick- skinned enough to handle it!
>>
>> At least, I thought so. Then the AI apocalypse hit in 2026.
>>
>> As a response to my frustration with the lack of support the user 
>> community is giving to open-source developers during this INCREDIBLY 
>> challenging time, I decided to close off a bunch of my public 
>> repositories. Because, hey, I don't want to directly train the 
>> technologies that will likely destroy the whole economics behind open- 
>> source software development. So I closed off repositories for things 
>> I'd voluntarily made public, including dropping any QGIS plugin that I 
>> wasn't directly using myself anymore, and that wasn't funded or in use 
>> by my customers (or where a better native tool now exists). And that 
>> included the SAGA NextGen plugin. I have no use for it, and none of my 
>> customers use it, and it's a PITA to "maintain".
>>
>> I knew that by doing so I'd be stirring up trouble, and honestly, that 
>> was partly my intention! I wanted to force a discussion about this, 
>> and raise widespread attention to the issues that would otherwise go 
>> unnoticed. It's the SAGA plugin today, but tomorrow it could easily be 
>> QGIS itself, or GDAL, or PostGIS, or PDAL, or ... 😱
>>
>> My personal preference would be that we continue to port useful tools 
>> from SAGA to native QGIS versions of these tools. I've done this in 
>> the past (see https://github.com/qgis/QGIS/pull/53794 <https:// 
>> github.com/ qgis/QGIS/pull/53794>, https://github.com/qgis/QGIS/ 
>> pull/61722 <https:// github.com/qgis/QGIS/pull/61722>) for tools that 
>> I need myself, or that my customers rely on, and the QGIS native tools 
>> are so much better (***FOR QGIS USERS***) then calling out to the SAGA 
>> versions. They have full format support for all the data sources QGIS 
>> supports, they work with massive rasters without memory issues, and 
>> they are much faster as they don't require data conversion to 
>> intermediate formats. And on top of that, they "just work" everywhere 
>> QGIS works -- there's no fussing around with SAGA version 
>> compatibility, and no security risks with python code shelling out to 
>> run random batch files.
>>
>> (Please understand that I'm not insulting the SAGA developers or their 
>> versions of these tools here... in my experience the SAGA developer's 
>> logic is great, the code is well written and the algorithms themselves 
>> are well designed. It's a testament to the SAGA developers how easy it 
>> is to port the tools to QGIS, they are very readable and well 
>> documented. My point is that we offer a better experience to **QGIS** 
>> users by porting the tools to native equivalents using QGIS API 
>> directly).
>>
>> If anyone has particular SAGA tools they rely on for their work, then 
>> please reach out and I'll let you know how much it would cost to 
>> sponsor a port of that tool.
>>
>> Finally, please note that I didn't delete the plugin repository, I 
>> just made it private instead of public. I'm happy to temporarily make 
>> it public again if someone wants to fork it, but after they do that 
>> I'll then permanently erase my repo. If someone wants to do this then 
>> let me know and I'll re-open temporarily.
>>
>> Nyall
>>
>>
>>  >
>>  > According to reports in the QGIS community’s Telegram group, 
>> maintaining this plugin is becoming increasingly difficult due to 
>> developments in the SAGA project, which can cause the plugin to stop 
>> working.
>>  >
>>  > I recall that until a couple of years ago, SAGA was, like GRASS, a 
>> resource installed directly within QGIS, but then, precisely because 
>> of the difficulty in keeping up with SAGA’s developments, it was 
>> decided to treat SAGA as a third-party resource accessible via plugins.
>>  >
>>  > I believe it is right that this important resource should not be 
>> maintained on a voluntary basis by a single developer/user, but that 
>> it should be taken on by the community.
>>  >
>>  > Do you think it would be a good idea to propose to the Steering 
>> Group that its maintenance be taken on directly by the QGIS.org 
>> Foundation and that a certain sum (1000–2000 euros?) be set aside in 
>> the annual budget for its maintenance?
>>  >
>>  > Thank you
>>  >
>>  > stefano campus