Open-source software is often described as “free,” a cornerstone of the modern digital world available for anyone to download, use, and modify. But this perception of “free” masks a growing and invisible cost—not one paid in dollars, but in the finite attention, time, and mounting pressure placed on the volunteer and community maintainers.
This hidden tax is most acute when it comes to security.
Jody from Geocat, a long-time contributor to the popular GeoServer project, pulled back the curtain on the immense strain that security vulnerabilities place on the open-source ecosystem.
His experiences reveal critical lessons for anyone who builds, uses, or relies on open-source software.
In Conversation
GeoServer and the Hidden Cost of “Free”
Daniel: You’ve been involved with GeoServer since 2003. Let’s talk about vulnerabilities and the idea that open source is becoming more expensive.
Jody: Vulnerabilities exist in software regardless of whether it’s open source or proprietary. In recent years we’ve seen high-profile cases — Log4Shell being the most notorious — that caused considerable disruption to society. In response, regulators around the world are starting to use legal tools to hold the software community more accountable. The challenge is that there’s a fundamental mismatch: regulators are used to working in a financial economy where fines create accountability. But open source runs on an attention economy. If you start fining us, we quickly lose interest and go elsewhere — and that wouldn’t be good for society either.
Daniel: What do you mean by the attention economy?
Jody: Open source thrives on attention — updates, new features, bug fixes — and all of that requires time. Money here is just a proxy for time. If you need my attention to look at a problem, you can pay me and I’ll go do the work. The growing volume of security vulnerability reports is an increasing claim on that attention, and somebody needs to pay for it. Meanwhile, customers are typically paying for new features, not maintenance. There’s a fundamental mismatch there.
When Regulators Treat Open Source Like a Vendor
Daniel: As a product owner at Geocat, your customers are paying you to handle security. What about projects that don’t have that backing?
Jody: That’s where it gets difficult. Geocat customers were patched well before any public disclosure — that’s what it means to have a vendor relationship. The problem arises when organizations outside our customer base assume that same vendor relationship with the open-source project. We’ve had national security agencies in Europe contact GeoServer directly with threats and tight deadlines, treating us as if we were a commercial vendor. We’re not. We had to reach into the Spanish National Authority to find the original researcher, establish a relationship, and work with them to at least fix the documentation around the vulnerability they’d reported.
Daniel: So they weren’t a client of Geocat at all?
Jody: No. Just a member of the open-source community, but acting as though disclosure pressure was a legitimate tool to use against us. It assumes a product vendor relationship rather than a community relationship.
The GeoServer Remote Code Execution Vulnerability
Jody: In June 2024, GeoServer dealt with one of the most severe vulnerability classes possible — a remote code execution vulnerability in how we evaluated XPath expressions. This allows someone to trick the software into running arbitrary code on the server. Our policy is to wait until fixes are ready for both stable and maintenance releases before any public disclosure, giving the community time to patch before attackers know the details. We made simultaneous releases and gave everyone two weeks to upgrade before going public at the end of June.
Daniel: What happened after you disclosed?
Jody: The very next day, security autoscans started probing to identify vulnerable GeoServer instances. The day after that — July 2nd — black hat attackers began automating attacks against GeoServer instances worldwide. I gradually learned that these attackers had lists of tens of thousands of GeoServer installations to target. I have no equivalent ability to reach that community — I can write a blog post or publish a CVE, but there’s a severe information imbalance. Attackers had better intelligence about who was running GeoServer than I did.
Taking Control with CVE Numbers
Daniel: Is there any way to address that communication imbalance?
Jody: One of the best practices we’ve adopted is taking control of the CVE process. Rather than having a national agency assign a vulnerability number with tight deadlines attached, GeoServer now uses GitHub’s Security Advisory database to issue CVE numbers ourselves. This lets us control when public disclosure occurs. Security researchers and tools scan for CVEs automatically, so publishing our own CVE reaches a far wider audience than our blog ever could. Interestingly, some people at this conference told me their national agency had scanned their infrastructure, identified unpatched GeoServer instances, and given them two days to fix them — with an offer to help. The same regulatory infrastructure that felt oppressive when directed at us actually helped spread the message.
Funding Security Work — A Very Hard Sell
Daniel: Who pays for all this security work?
Jody: That’s the hard question. Most procurement departments are set up to pay for deliverables — something they can point to. Security maintenance is the opposite: we can’t tell you what we’re looking at or what we’ll find. GeoServer highlights security as something people can sponsor, but it hasn’t been well-responded to. My gut feeling is that it’s a very difficult sell compared to sponsoring a specific new feature.
Daniel: What would an ideal solution look like?
Jody: I’d love to see OSGEO have a security response fund — money set aside that a project in crisis could draw on quickly, similar to how they helped GeoTools with a legal challenge a couple of years ago. Right now, GeoServer relies on core contributors from member organizations each volunteering time on a security list to assess new reports. Whether an issue gets addressed quickly depends on which organizations feel enough stake to invest the time. That’s a fragile model for something this important.
The GeoServer 3 Crowdfunding: Being Brave Enough to Ask
Jody: One real breakthrough was the GeoServer 3 crowdfunding campaign. For a long time, the team avoided talking about the roadmap publicly — if you mention a planned feature, people assume it’s being built and stop contributing. But this time, a consortium of companies — Camp to Camp, Geocat, and Geos Solutions — turned an abstract “we need to fix these things” into something concrete: GeoServer 3, with a version number and a goal. The response was overwhelming. We exceeded the funding target and we’re on track for a March release. The lesson: be brave enough to ask for help, make it concrete, and give it a name people can rally around.
Daniel: What can other projects learn from that?
Jody: Honestly, the hardest part is being brave enough to ask. We learned early not to talk about roadmaps. Breaking that habit and making a public call for financial support was the real hurdle. And it needs to be specific — not “we need funding for maintenance” but “we need funding for GeoServer 3.” That version number was the attention-grabber. That said, it’s a rabbit you can probably only pull out of the hat so many times. The ongoing challenge is figuring out how to fund regular maintenance work rather than just dramatic version milestones.
Advice for Projects: Protect Your Contributors
Daniel: What advice would you give to smaller open-source projects facing these pressures?
Jody: A few things. Look at how the curl project handles it — when asked to fill out compliance documents or threatened with disclosure, they offer the party a chance to become a paying customer. If someone is treating you like a vendor, give them the option to be one. Some projects have simply decided to treat security vulnerabilities like normal bugs — publicly listed, no special urgency — to undercut the leverage of disclosure threats. And consider whether being under an umbrella foundation like OSGEO helps, both for credibility and for access to shared resources in a crisis.
Jody: But the most important thing: be kind to your contributors. Security overhead is a real and growing burden on top of everything else these volunteers carry. Contributor burnout is very real, and these added demands make it worse. The people building the tools society depends on deserve support, not just demands.
