[OSGeo-Discuss] Using AI in OSGeo projects - Notes from the Timisoara BoF

Sat Jul 25 12:10:15 PDT 2026

 Hi Adam,

Thanks for moving this discussion along, each response brings more ideas to
the table (along side the poor cat). Personally I am just coming up to
speed on these topics and ending up with more questions than answers.
Aside: I kind of feel like "software has eaten the world" is morphing into
 "LLMS are eating the software".

Pulling some ideas together I have a slightly different take on "fork it":

   - The codeburg policy
   <https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html>
   recognizing vibe coding as a "software team of none". This matches Ivan's
   insight that this approach is initially rewarding, and has a different
   development/reward curve than hands on development.

   - One article that resonates with my experience is Why Software
   Factories Fail
   <https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html>
   on software factories (old term) and setting expectations for light-on
   (with human review) or lights off (no human review). While the terms are
   creative they captures the expectations folks have around these
   technologies.

   - I also appreciate the effect we see first hand when reviewing changes
   proposed by LLMS: shotgun surgery with many small changes proposed, rather
   than keeping the big picture / or long term maintenance picture in mind.

Vibe coding really matches software team of none, or more extreme 'lights
off" software factory, but has a short term strength, long term weakness.
Our established software projects really emphasis maintenance: which is a
cultural difference making such interaction unrewarding for both parties.
As we are experiencing this friction "fork it" is a sensible response.
Much like Overture Maps a separate dataset for LLMS folks to play in,
allowing Open Street Maps could remain community powered.*

In personal terms it is not emotionally rewarding to review changes
proposed by LLM, there is no sense of community and connection and building
something together. So I will understanding if someone forks GeoTools for
vibe coding. I do not wish to be included in review part of the LLM loop -
best I can hope for is the human to report back and together we can learn
from their experience for roadmap planning.

I am also working through the "fight fire with fire" approach of using LLM
tools to handle maintenance burden:

   - Last weekend the Linux Kernel published over 400 CVEs
   <https://seclists.org/oss-sec/2026/q3/198> over the of a day. I was
   aware that spring-framework addressing a wave of vulnerability reports
   <https://spring.io/blog/2026/06/01/spring_and_security_in_the_times_of_ai>,
   but seeing the Linux kernel similarly affected should be sobering for
   everyone. I expect this has influences Linus pragmatic response.

   - Our OSGeo projects are amazingly underfunded for the value they
   provide to society. Combined with regulation around vulnerabilities we
   should as leaders be planning for some stormy days ahead.

The BOF was good at recognizing that LLMSs are involved in economics of
software now, both closed-source, and in our open-source attention
economy.  This is the context where I appreciate using LLMS to "fight fire
with fire" - using such tools to review incoming pull requests and
vulnerability reports.  The goal being to make better use of the
maintainers we already have, and to help alleviate burn out.  (This is also
the context where I appreciate the effort  Jeroen and the OSGeo board are
putting towards funding and sustainability.)

And then we have some fundamental challenges:

   - LLMs capturing some value from the raw FOSS4G source code, escaping
   feedback loop each licenses establish for sustainability.
   - It is easy to dismiss those using LLMs (training on foss4g source
   code) as not in position close the loop and contribute back directly.
   However I do not wish to lose the "expert users" -  using their technical
   knowledge to "vibe". Such knowledge and experience would be good attract to
   our community.
   - The clash between LLMs memorizing
   <https://arstechnica.com/features/2025/06/study-metas-llama-3-1-can-recall-42-percent-of-the-first-harry-potter-book/>
content,
   and Free Software Licenses requiring works to maintain license. For a
   providence review I wonder if it is even possible to quantify how much is
   memorized, and end up with something similar to the music industry
   accounting for sampling - lol.

Seth you are correct that each project team should think through what they
want to do. Each one of those "incubation" priorities are in response to a
specific concern (often directly answering FUD), or success factor (vendor
neutral leadership).

The underling goal is to produce software that our community can trust to
work with and manage the geospatial data in our care for years to come.
- -
Jody Garnett

On Jul 22, 2026 at 3:46:11 AM, Adam Steer via Discuss <
discuss at lists.osgeo.org> wrote:

> Hi all
>
> The community seems really quiet on this topic, here and on discourse -
> aside from some key voices! While these are important and not to ignore,
> OSGeo is more than just a few euro-aligned guys (myself included). My first
> response about the arguments of Linus is this: is OSGeo really the
> community that wants to take the attitude "well, you can always fork it"?
> What's the relevance of this to OSGeo and its approach?
>
> Or, is it a dead cat? (see:
> https://en.wikipedia.org/wiki/Dead_cat_strategy)
>
> I've written in another discussion about community, environmental and
> social harms already caused by large scale expansion of the tools we
> collectively (and wrongly**) call "ai". And thought that this research
> might be good to add to the discussion:
>
> https://osf.io/preprints/psyarxiv/5y6m4_v1
>
> The TL:DR is the title: "AI advice suppresses people’s willingness to say
> “I don’t know”, even when the advice is wrong and accuracy is incentivized"
>
> What has this to do with OSGeo? And writing code?
>
> Well, is OSGeo only writing code? Or is it also about all the support
> systems that enable writing code? Or *do things* with the code? Or *fund*
> the code? Or develop (and evolve) systems of governance for funding,
> writing, sharing, and using code? I've always had the view that OSGeo is
> all of the above. And in all of that system, being able to update our
> thinking, our approach - is critical. And we need to be comfortable with "I
> don't know".
>
> All of those words sum up to:
>
> I'm very uncomfortable with the approach "well, you can always fork it".
> I'm also uncomfortable with the particular fallacy of technological
> inevitability about "ai".
>
> So where do I think OSGeo projects should go with that?
>
> Where they choose to, understanding the risks carried - from plain wrong
> code to excessive maintainer workload to losing valuable community to valid
> criticism on environmental, social and psychological grounds. Or being told
> they're being left behind (by what?)
>
> I think Even makes a good point: are we here to do a technology at all
> costs? Or here to do a community that cares about how technology is made
> and deoplyed? or something else?
>
> Maybe all of this doesn't even resonate in a technology focused
> organisation. I really wanted to write on behalf of a  (maybe imaginary)
> part of the community who sees OSGeo in a much broader context.
>
> Cheers,
>
> Adam
>
>
> **I do own a degree in psychology for what that is worth, I feel there's a
> little imprimatur there on making this kind of call
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20260725/110d0f16/attachment.htm>