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 ([email protected]) 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-
[email protected] <mailto:[email protected]>> 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
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
