[QGIS-Developer] SAGA GIS plugin maintenance

Thu May 21 16:55:13 PDT 2026

On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer <
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 followed,
when the built-in SAGA plugin was removed and it went from being an
out-of-the-box, "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/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
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/6a68556b/attachment.htm>