Welcome to another edition of SFTW Convos! This week’s edition features Guy Coleman, a post-doc researcher in Denmark, who is the driving source behind the open source precision weeding project called OWL. For you Harry Potter fans, this is not “Ordinary Wizarding Levels”, but OpenWeedLocator.
Open Source is not a new concept in the technology world. One of the world’s largest operating systems in the server market called Linux is an open source system. Linux dominates cloud computing, powering over 90% of cloud infrastructure. It is the backbone for major public cloud providers like AWS, Google Cloud Platform, and Microsoft Azure due to its scalability, security, and cost-effectiveness.
Open source is not as prevalent in agriculture, though there are some initiatives which have been ongoing for some time.
Guy Coleman has built an open source precision weed detection system using mostly off-the shelf hardware components and software. It is now supported by a world wide open source community. Guy is a strong proponent of open source. I will admit I was very skeptical about open source in agriculture, but after this interesting conversation, I am less of a skeptic than before. I hope you enjoy this conversation as much as I did.
Given this is a discussion about open source, this edition is available to all subscribers. (Even though free and open source are different concepts).
Guy also writes a regular newsletter about open source. .
Scaling Regen Ag Starts with Better Data
Farmers Edge is building the digital backbone for regenerative agriculture—designed to simplify Scope 3 reporting and deliver credible results, fast. With Managed Technology Services built for agribusiness, Farmers Edge connects real-time field data to your sustainability goals across every acre and every grower in your network. From in-season tracking to end-of-year proof, Farmers Edge makes regen ag measurable and manageable. If you're serious about scaling impact and reporting, this is the infrastructure that makes it possible.
Summary of the Conversation
In this conversation, Guy Coleman, a postdoctoral researcher at the University of Copenhagen, discusses his journey from medicine to agriculture, focusing on precision weed control and the potential of open source tools in agriculture. He highlights the need for precision weed control to address issues like herbicide resistance and the importance of community engagement in developing open source solutions.
Guy emphasizes the need for a supportive infrastructure and governance structure to facilitate the growth of open source agriculture, while also addressing the barriers to adoption and the organic interest in these tools. In this conversation, Guy Coleman and I discuss the potential of open source solutions in agriculture, focusing on the OpenWeedLocator project. We explore various business models, the importance of local entrepreneurship, and the challenges of integrating open source technology with existing systems. The discussion also highlights the need for collaboration among different open source initiatives and the opportunities for future growth in the sector. We address the complexities of hardware integration and the metrics for measuring the success of open source projects.
Precision Weed Control
Rhishi Pethe: Guy, thanks for joining. Could you walk through your background and what you’re working on now?
Guy Coleman: Thanks for having me on, Rhishi. It’s a pleasure to be here. I’m Guy, a postdoctoral researcher at the University of Copenhagen, based in sunny Denmark. I’m originally from Australia, and I grew up with a bit of both worlds, a mix of city life and country life. My dad’s a farmer out in the countryside, and I lived in the city with my mom. I’ve always been interested in agriculture and tractors, but I never really thought of it as a career path.
That changed in 2016 when I decided to swap from medicine to agriculture. After traveling and working as a research technician, I realized that agriculture, and weeds specifically, wasn’t just a side hobby for me. It was something I could actually build a career around.
From there, I shifted into studying ag technology, trained in ag science, and went on to do a PhD. I spent some time working in precision agriculture up in Narrabri, about seven hours north of Sydney, and also studied in Texas for a bit with Dr. Muthu at Texas A&M. I’ve been based in Denmark for a while now, and I did my PhD back in Sydney. So I’ve moved around a fair bit.
Most of my work has focused on weed recognition and precision weed control. I’ve experimented with laser weeding, detection technologies, robotic platforms and open-source tools. I’m also self-taught in software development and machine learning.
Rhishi Pethe: Why do we need precision weed control? What problems go unsolved without precision weed control, and how does this approach fix them?
Guy Coleman: It goes back to something my supervisor shared with me, a comment from a farmer in Western Australia, Andrew Messina. He runs a huge farm, over 10,000 hectares. When he goes out into his fields, he sees very few weeds. Western Australia’s pretty marginal country, you put in minimal inputs, hope for good weather, and aim for decent yields.
But even though the fields look clean, he still has to spray the whole thing. He knows that if he misses even a single weed, things like wild radish or ryegrass, which are big problems there, they’ll produce thousands, even hundreds of thousands, of seeds. And if you let even one or two plants go, you end up with a huge problem in future years because of the seed bank. Seeds can stay viable for seven, ten years, or even longer. There are cases where seeds came back after thirty years in old moldboarded fields. So even though it doesn’t really make sense, he sprays everything, because the risk of missing a few weeds is too high.
The better option would be to just spray the weeds. But to do that, you need to know exactly where the weeds are. And to know where they are, you need some kind of weed recognition system. That’s where precision weed control comes in.
Precision weed control covers two things. First, detecting the weeds, mostly with cameras these days, though it doesn’t have to be, and second, applying something to control them. And it’s not just herbicides anymore. There’s a whole range of exciting new tools, lasers, electrical weeding, mechanical systems, lots of really interesting developments happening.
Rhishi Pethe: First, we aim to cut inputs, pinpoint weeds and treat only the hot spots instead of blanketing the whole field. Second, herbicide resistance keeps rising. Does that strengthen the case for precision weeding?
Guy Coleman: That's definitely a big driver, it increases the risk when you miss a weed.
If you miss a weed that’s a really soft competitor, one that doesn’t challenge the crop much, then maybe it’s not a big deal. It might not cause any real issues, and honestly, it’s probably not even worth worrying.
But herbicide resistance changes that. It raises the stakes. In Western Australia, across Australia and even globally, herbicide resistance is a major issue. And Western Australia is a real hotspot. Even a single missed weed could turn into a huge threat across the entire farm if it spreads. From a farmer’s perspective, that risk drives the need to manage every weed, every seed, every field, every year, which is actually one of the mottos some extension groups use in Australia.
That's one of the big drivers. And of course, there are other benefits too, like saving on inputs, reducing environmental impact, and a whole range of additional upsides.
The need for open source
Rhishi Pethe: You’ve flagged three core challenges.
First is risk. Miss even a few weeds and they reseed, crank up the pressure, and the problem compounds.
Second is cost. Blanket-spraying wastes inputs we could target surgically.
Third is the seed bank. Escaped weeds leave seeds that can sit dormant for decades.
In the past few years the space has exploded, John Deere’s See & Spray, laser weeders, mechanical weeders, startups and incumbents are all in. Yet you’ve chosen a different route with open-source tools built by a community.
So why open source? What makes it a viable model for solving these tough problems? And why do you think so few ag-tech players have tried it, even though it’s common in software?
Guy Coleman: That’s a really good question. I’ll probably start by giving some background on how I got into open source and why I’m so interested in it.
It really comes from how I taught myself to code and learn about software. I leaned heavily on open-source tools and resources that people were kind enough to publish online. Back when I was learning to code, around 2018, 2019, I was diving into OpenCV, Python, and a few online tutorials. But everything was focused on things like detecting dogs, cats, or figuring out if muffins looked like chihuahuas, that famous example!
I wanted something different. I wanted to work on agriculture. I wanted something practical that I could use in my day-to-day job. So for me, it became important to create something agricultural that others could also use to learn coding, something that would combine learning with real-world application.
That tied back to my own career shift from medicine to agriculture. I wanted to make agriculture more appealing to a broader group, not just to people like me who studied ag science from the start, but also to people getting into machine learning and looking for real-world applications. I wanted agriculture to be one of those outlets.
That’s really where the OpenWeedLocator came from, creating an open platform where people could build their skills and develop something practical at the same time. Open source just made sense.
As I went down this path, I realized agriculture has always kind of been open source at its core. Farmers have always shared knowledge, over boundary fences, at community meetings, not necessarily on GitHub, but the spirit was the same.
Historically, if you bought a seeder or a plow, your “open source tools” were a welder, a wrench, and a grinder. You could modify things yourself. My dad does it, his neighbors do it, you see some pretty incredible homemade machinery on farms, all customized for local needs.
And that’s the thing about agriculture: it’s an industry built on niches. No two areas are exactly the same. When you try to force-fit one machine across all those different conditions, it doesn’t really work. Farmers need to adapt equipment to their local reality.
That’s relatively easy (though never look at my welding skills) when you're dealing with steel and a welder, you can tweak things. But when the tool is a black box of machine learning code behind proprietary curtains, it becomes almost impossible. Farmers end up completely dependent on companies or startups to deliver solutions. And with that shift, the power to innovate moves away from farmers, when historically, it always sat with them.
That’s not to say the people building products aren’t talented or efficient, they absolutely are. It’s just that with so many niches, it’s far more efficient to give farmers the tools to innovate themselves. And the way to do that, with modern technology, is through open-source tools.
I think of it like sharing a base recipe. Bakeries are everywhere, you can easily find a Danish pastry here in Denmark, and pretty much anywhere in the world. I could look up a recipe and try to bake it myself. But most of the time, I don’t. I just go buy one. It’s easier, cheaper on an individual basis, and the baker can offer way more variety than I’d manage on my own. The point is that sharing the base recipe doesn’t kill the business model. If anything, it increases it, because I know I could do it myself, but I'd rather pay someone better and faster than me to do it. I don’t feel forced to do it, I just do it because I want to.
That’s the mentality agriculture needs. We should empower people to adapt solutions themselves if they want to. But at the same time, there's huge potential to build better products and services around those open platforms.
Rhishi Pethe: Both examples work really well, the welders, the blacksmiths, the local bakers. But one difference jumps out to me. They already have an established infrastructure. There are hundreds of thousands of welders and bakers around the world. All they need is a recipe, and they can tweak it to fit local tastes.
Take Danish pastries, for example. The version made in Texas is probably a little different from the one in Denmark. I’m sure a Danish person would call it an abomination, but it caters to local tastes. There’s already a network of skilled people who can take a base recipe and turn it into a local business by modifying it for whatever niche is needed.
But as technology gets more complicated, that model becomes harder. You might be able to repair a landline phone at home. But there’s no way you’re fixing an iPhone, it’s just a much more complex machine. So what kind of infrastructure or ecosystem do we need to actually support open-source frameworks in agriculture?
Let’s take Linux as an example. It’s open source, and there are hundreds of thousands of developers contributing to it. Companies like Red Hat have even built entire businesses by supporting Linux customers. What’s the analog in agriculture?
Guy Coleman: I think about it a little differently. I’ll challenge you a bit on the idea that you can’t fix an iPhone. I think we absolutely should be able to.
But for me, it’s not about giving people access to every single layer of complexity. There’s a lot of boilerplate and basic stuff people don’t need to touch. Instead, it’s about building some form of modularity into the system.
If we extend the baking example, I don't need to grow a whole field of wheat just to bake a loaf of bread. I just go buy flour. In the same way, we can abstract away some of the underlying complexity so the ecosystem is still usable. Tools like Python already help manage that by being high-level and accessible. For me, it’s really about opportunity, giving people the chance to fix things or build on them if they want to.
For example, if a farmer wants to extend some detection code to a new crop, but they don't have access to the underlying framework, say the company built it in TensorFlow and locked it down, they’re stuck. They can't collect their own data, train a model, and deploy it on their crops. They have to wait for the company to do it, and that could take years.
If you give farmers the opportunity, the ability to update or adapt the tools themselves, you reduce their risk. They’re less dependent on company roadmaps or the swings of the global ag-tech investment markets. It gives them more control over their own destiny. From an infrastructure point of view, I think there are a few key pieces like standardizing data collection, making model training accessible, and connecting trained models back into platforms easily.
I often think of it like a three-point linkage for model development.
Is there a way to standardize across all this equipment? Maybe that’s something as simple as agreeing on a framework, like PyTorch instead of TensorFlow. Some standard formats for models and data. It's complex, sure. But it would be a powerful way to empower farmers to start collecting their own data, training models, and building solutions.
At a lower level, you still need modular software systems that work together, and maybe even some modular hardware designs too. But you don't need every single chip design or the deepest low-level engineering exposed. It’s more about offering modular parts people can plug and play if they want to. I think when you look at the really hardcore definitions of open source, they might not fit agriculture perfectly. We don't necessarily need to share every detail. Instead, it could be a more open collaboration model, one that still gives farmers the ability to innovate without having to meet the strictest software or tech open-source standards.
The approach would open up a lot of new industries and growth opportunities like a marketplace for models, a marketplace for shared datasets, and a new role for tech-savvy agronomists who can work with farmers to build and share open tools.
I think there’s real potential there.
Incentivizing an open-source community
Rhishi Pethe: You mentioned modularity, and as soon as you go modular, you need components that are interoperable. It’s like building with Legos: the pieces have to fit and work together. You also need a community of contributors. Open source can’t just rely on one person, you sitting in Denmark, doing all the coding. That’s not scalable. How do you incentivize a broader community to contribute to an open-source agriculture project like this?
Guy Coleman: It’s a tricky one. I don’t think there are any clear-cut answers here.
I often look at something like AgOpenGPS as a great example. It’s an open-source GPS autosteer system for tractors, developed by Brian Tischler up in Canada. And it’s built a really strong community of people who contribute, learn, and keep pushing it forward. It’s a far more advanced and developed platform than OpenWeedLocator at this point.
What’s interesting is that AgOpenGPS feels really organic. People share a common interest and want to develop it. Farmers generally seem very supportive of it.
But if you look closely, the Venn diagram of farmers who are also software developers and have the skills to contribute, is pretty small. Even though I speak with a lot of farmers who are interested, the overlap when it comes to coding or even electrical design skills is quite narrow.
That said, I think agriculture offers another way to contribute that isn’t just about coding. Farmers using the tools in the field, breaking things, and giving feedback, that’s just as valuable.
For example, if a farmer’s camera screws fall out and short a board, which actually happened with one of our early OpenWeedLocator users, that feedback lets us fix the design. And when those kinds of issues are documented publicly, future companies can learn from them too. Simple stuff like, “Hey, make sure you use Loctite on this part” can prevent bigger problems later.
When it comes to building an open-source community, I think there’s often a belief that it has to be purely community-driven, that it can’t involve any commercial effort. But I’d like to challenge that.
The way I see open source is about sharing a base recipe. And I think companies can do that strategically. They can share foundational tools, create new markets, and grow organically, without needing to force an entirely free, unstructured community. I really believe you can build a company around open-source principles. Share the base recipe, and then offer services, products, and value on top of it.
You can see it happening already with machine learning.
Take RoboFlow, for example, they use a freemium model where you can access open-source tools, but if you want more advanced features or private models, you pay. Or look at Hugging Face, they’ve raised tens of millions of dollars by building an open-source community first and then offering services on top.
Even companies like Ultralytics are doing something similar. There are plenty of examples now where open-source products attract people into an ecosystem, and once they’re there, some of them are willing to pay for services, support, or premium features.
Rhishi Pethe: That’s interesting. Looking at my checklist for what open source needs, you do have a shared pain point. Farmers deal with so many local nuances that it’s tough to find one product that works broadly, which is what most companies aim for. I don’t blame them for trying, but it’s harder.
As a farmer, you might not want to wait around for the perfect solution. You’d rather get the best recipe, tweak it for your context, and get moving. I think that mindset is already there.
When you’re inside a company, you’ve got built-in governance for managing code, releases, and support. In open source, it’s different. So how do you handle governance? Who manages the code, approves releases, and keeps things on track? And how is that working so far with the OpenWeedLocator project?
Guy Coleman: I think it’s really important to have some kind of central point, some focal point, for an open-source project. There needs to be someone managing a stable version of the product, someone people can go to when they want a base to build from. I do think it’s important to have a company or some kind of structure built around an open-source tool, something that looks after governance, version control, and the overall direction of the project.
There’s been a lot of debate about this, even going back to the 1990s and 2000s. If you look at some of the early discussions between people like Linus Torvalds, Richard Stallman, and Eric Raymond, there were some really interesting arguments about what governance should look like for open source.
But at least in agriculture, it’s important to have some coherent “go-to” point. A place where people can ask questions, suggest changes, or contribute ideas, while still keeping the development open and transparent.
With the OpenWeedLocator, I think the next steps are to start building a company or a foundation around it. Something similar to what Raspberry Pi has done. They have both the Raspberry Pi Foundation and the Raspberry Pi Company, one focused on education and community, the other on efficiently delivering products and services. That’s the kind of structure I’d like to see for OWL.
Right now, it’s still very much me writing code, and people making suggestions or forking the project. For example, there’s a guy in the U.S. who forked the repository and has been porting it over to work on the Jetson Nano platform. That’s a great example of how open source allows projects to move in different directions, and maybe come back together later under the same brand, under the OWL name.
Just like Raspberry Pi devices often say “Powered by Raspberry Pi,” there could be opportunities to build a “Powered by OWL” brand around OpenWeedLocator too. That could open up new revenue streams without closing off the community.
I really believe there are ways to explore business models that go beyond the traditional “build a closed product and sell it” model. There’s a genuine opportunity to have farmers not just working with the product, but actually helping develop it, bringing their insights directly into the innovation process.
Rhishi Pethe: You mentioned you’ve studied the early open-source debates, people like Linus. Are there any lessons you’re taking from them, especially given agriculture’s unique challenges, how fragmented it is, how every farm operates a little differently?
Guy Coleman: I think some of what Richard Stallman wrote back in the late '80s and '90s is really interesting. He worked on GNU, and his philosophy was very much that you can’t own software, that it has to be free, but ‘free as in speech, not as in beer’ as he famously wrote.
He talked about it a lot, and made some really important distinctions between different definitions of free. With Free and Open Source Software, FOSS, free doesn’t necessarily mean you don’t pay. And I think that's an important point.
Free in that sense is more about freedom: the freedom to use, modify, build and share software, not necessarily that you get it without cost.
I think Stallman was more of the opinion, you shouldn’t pay for software licenses at all, that it should always be open. Personally, I think there are cases where it’s important to have some kind of revenue stream to support ongoing development and to be fair, Stallman was of a similar opinion, just that this shouldn’t come at the expense of any software freedoms. It should be free in the sense of freedom, to use it how you want, within some kind of license that still helps fund the project and make it economically sustainable. Otherwise, it’s hard to keep these efforts alive long-term.
And there are some really interesting comments from Linus Torvalds too. One that stuck with me is something I wrote down.
"Don’t ever make the mistake that you can design something better than what you get from ruthless, massively parallel trial and error with a feedback cycle."
He absolutely nails it there. That’s where open source could be such a huge advantage for agriculture. Because ag-tech is already a niche, the talent pool is already limited. While the individuals working inside companies are excellent, it’s potentially much faster to innovate if you open it up. You can tap into a global talent pool and get faster feedback by letting more people adopt, test, and build on it in ways you might never have thought of. I've found that even with OWL. I’m just a single person working on it, and yet other people, coming from completely different perspectives, find things or suggest changes that I never would have come up with myself. It’s humbling, honestly. And powerful.
And that’s what I love about what some of these early open-source pioneers talked about, this idea that real innovation often comes organically. You can't predict exactly where it will go. But if you create the conditions for it, it can evolve into something much stronger.
I think that kind of organic, open-source growth in agriculture is still really unexplored. And if someone genuinely leans into it, you just don’t know how far it could go.
Barriers to open source
Rhishi Pethe: You’re touching on something important. If you look at the U.S., 2% of the population is involved in agriculture. So the "farmer" circle in that Venn diagram is already tiny.
Now, layer on top of that: how many farmers are actually willing to get their hands dirty, take a base recipe, and modify it for their own needs? What's the real work involved? And what’s the opportunity cost for them?
From an open-source standpoint, what are the biggest barriers you see in getting there? And why do you consider those the biggest challenges?
Guy Coleman: First, it’s about getting traction in terms of investment. Being able to hire people or build a team takes funding, but the challenge is that OWL doesn’t have traditional IP. I haven’t really gone out and asked for non-university or non-grant funding yet, but I know that if you’re talking to venture capitalists, it’s hard. You can’t sit across the table and say, "Here’s your exclusive IP." Because it’s open source.
And I get why they hesitate, it makes sense from their perspective. But it does create a barrier when you’re trying to scale something like this.
Second, for me personally, it’s the time commitment. Most open-source projects face this. Because it’s not something paying my wage directly, it’s driven purely by my interest and passion. And while it’s a huge strength that OWL is open, so if I ever got bored or had to step away, it would still exist, it also means the burden to keep pushing it forward sits heavily on my time and energy.
Then there’s also the governance side. Figuring out the right structure for how the project should grow and be managed is another big challenge.
Interestingly, on the adoption side, it’s almost the opposite problem. There’s so much interest. People are excited. They want to use it. And I often find myself saying, "Look, this isn’t quite ready yet. Maybe use it as a learning tool for now and then move on to a more polished commercial product." So the organic interest is definitely there, it’s strong. It’s really the business side, funding, scaling, governance, that’s been the tougher part for me personally.
Rhishi Pethe: Correct me if I’m wrong, but it sounds like you’re saying that if there’s a strong business model or incentive structure, more people would be motivated to contribute and experiment.
For example, you’re not getting paid for the work you’re doing on this project. But if there were a business model where someone could make money from this, it would get a lot more people interested.
Of course, there are passionate contributors out there, I’m not denying that at all. But part of the reason Linux has worked so well is because there’s a commercial model around it: support services, a big active community, and clear incentives.
I think you’re really pointing at the key issue: what’s the right business model that not only shows people the value, but also gives them a real return, beyond just getting a low-cost, working solution for managing weeds?
One example comes to mind. I’ve mostly seen it in Africa and Asia, take Hello Tractor, for instance, out of Africa. In places like India too, you’ll find local entrepreneurs who act as connectors. They match supply and demand, provide services, and earn a living facilitating those transactions.
Could something like that work here? Imagine someone in Denmark, or anywhere, who’s an engineer, knows how to code, and services 20 local farmers. They take your base recipe, customize it, help farmers run it, and get paid a little for their trouble. It would create a network of local entrepreneurs.
I’m thinking about two risks. First, without the right business model, it’s hard to scale. Second, if something, God forbid, happens to you, yes, the project is open, but finding someone with your same level of passion to keep it alive might not be easy.
Guy Coleman: Maybe the best way to answer this is to just share how I’m thinking about the OpenWeedLocator business model for the future.
I agree that a structure like the one you’re describing, even if it’s less formalized, is a really strong way to create what I think of as a "globally local" model. Each person on the ground knows their environment best. They can offer services that are localized, not just in language, like needing a Danish translation of the manual for Denmark, but also in context, soil type, weeds, and farming practices.
We’ve already seen early signs of this happening organically with OWL. There’s a guy in the U.S. who’s really keen on building and supporting it locally. There’s someone in New Zealand who’s built a version and is starting a business offering precision spraying services. In both cases, they’re using OWL to get off the ground, and maybe later they’ll refine it even further into new products.
So I do think there’s an opportunity to formalize that collaboration. Instead of it being casual, just people I know and email with, we could move toward a more defined structure. Something like "Powered by OpenWeedLocator," where there’s accreditation, mutual support, and shared development. That way, any improvements made centrally, new features, better base recipes, could flow out to all these local groups. At the same time, it would support training and upskilling so everyone stays aligned with how the software is evolving.
That’s one model I’ve been thinking about, a way to create a more sustainable structure around OWL without losing the open-source spirit.
More broadly, in open source, there are other hybrid models too. You can strategically release limited pieces of code, like what Chris Laudando is doing with L&Aser. Or take Farm-ng’s robot, they’ve opened up an API that lets people build on top of their platform without giving away the entire system. In my view, that’s almost a form of open source, not in the strictest sense, but in spirit. They’re fostering community building and innovation around their product and running some fantastic community building competitions too.
Same with Bailey’s work at Leaf Agriculture, he’s put together a great GitHub repository that helps standardize agricultural data across platforms. He’s giving people tools to build with, but he’s still running a business. Again, that’s open-source thinking, even if it’s not pure by definition.
So I think there are ways to take that first step strategically. You don’t have to be an entirely open-source company. You can create a foundation that lets people innovate more efficiently around what you’ve built, without giving away everything.
Cross-pollination of ideas across other open source solutions
Rhishi Pethe: There are a bunch of other open-source efforts out there, FarmOS, AgOpenGPS, FarmBot, the Open Ag Data Alliance working on standards. Is there room for collaboration between all these different initiatives? And if so, what might that collaboration look like in practice?
Guy Coleman: I don't necessarily have a formal plan, but I do think it would be great to create more collaboration across open-source ag tools.
The obvious one would be between AgOpenGPS and OpenWeedLocator. I'd say around 50–60% of the people building OpenWeedLocator have had some involvement with AgOpenGPS, either through developing or using it. I’ve spoken with Brian [Tischler] a couple of times, and there’s definitely interest in integrating the two. It’s not something I’m actively working on right now, but it’s something I’d definitely like to see happen. And honestly, it might just happen organically. There are already a few people working on both projects at the same time.
That’s one of the strengths of open source, it allows this kind of natural evolution and crossover.
There’s also a project in Europe, an EU-funded effort, trying to bring some standards and collaboration across open-source ag tools. It’s a nice idea. But I think one of the challenges is that the tools often serve really niche purposes. Like with OpenWeedLocator, it’s laser-focused on weed detection. Integrating it with a full farm management platform doesn’t necessarily bring a lot of extra value, at least from my perspective. And that’s part of the challenge: unless there’s a clear benefit for the original developer, it’s hard to justify the extra work just for integration’s sake.
There’s also a real risk of creating yet another standard that doesn't get widely adopted, like that XKCD comic about standards where everyone says, "Let’s fix it by making a new standard," and then you just end up with one more. So you have to be careful.
When it comes to standards, the big players actually have a huge opportunity. If you're John Deere, for example, sitting on billions of images, you could release a dataset and a framework overnight, and instantly create a standard just by the sheer size and influence of your platform. Same thing with CNH or other large OEMs, especially if they don't yet have a strong weed detection play.
If they put out data, imaging specs, and protocols, startups would naturally want to work with that, because it would make sense for them to do so. And suddenly, your tools and specs become the de facto standard.
Startups, on the other hand, don’t have that luxury. If they release a "standard," it often just becomes another isolated effort.
But big players, with massive datasets and fleets, could organically create standards by simply letting people use their stuff. They wouldn’t even have to give everything away. They'd just make it easy enough for others to adopt and build on top of it. I’m not sure if it will happen, but to me, that’s one of the most practical ways to make standards work, by making things usable and accessible.
Integration with other equipment?
Rhishi Pethe: You don’t create standards by putting 10 people in a room and telling the world how it should operate, that never works. You mentioned integration with other systems. The OpenWeedLocator has to work on a piece of equipment that’s out in the field, either capturing data or taking action.
If you want it to not just detect a weed but also trigger a response, whether that's firing a laser, moving a mechanical weeder, or spraying, you need to integrate directly into the equipment’s actuation mechanisms. And those systems can vary a lot across different makes and models.
That’s a huge integration challenge. How are you thinking about solving that for OpenWeedLocator, especially to create even more value?
Guy Coleman: That's a really interesting one. The logical way to do integration would be through ISOBUS. And there’s actually a really nice open-source library called AgIsoStack++, it’s a C++ version of ISOBUS. I think there’s even a Python version now too, PySOBUS. But integrating into ISOBUS is really costly and time-consuming. I’ve spoken with some startups that have done it, and it’s a real challenge.
There are good examples, though, like PerPlant here in Denmark. They’ve built a sweet detection system, and they spent a lot of time making sure it works across different systems. When I was developing OWL, I always thought one of its biggest failures was that it couldn’t integrate with anything. It just worked on its own.
But then I had an interesting conversation through a friend, an agronomist in the Northern Wheatbelt of Western Australia. He was talking to a farmer, and when the farmer realized OWL didn’t have to connect to anything, his reaction was, "Wait, that’s great!"
For him, the biggest benefit of OWL was that it was effectively a dumb device. You just gave it 12 volts, turned it on and off, and it handled everything else itself. That really surprised me. What I thought was a weakness turned out to be a major strength, at least for some farmers.
Because now, they didn’t need to integrate it with a John Deere screen. They could hook it up to an old tractor sitting around, or an ATV, and go spot-spray without needing complex, expensive equipment. They didn’t have to wait for a $10,000 Trimble screen to free up just to run another system.
In a way, that simplicity became one of OWL’s biggest advantages. It reduces complexity. It opens up flexibility. And it lowers the barrier to using precision tools, even with older equipment.
That was a big learning for me.
Rhishi Pethe: Let’s say you’ve installed the OpenWeedLocator on an ATV and you're out in the field. As it moves, is it first creating a map of where the weeds are, and then you load that map later and tell a sprayer, "Spray here"? Or is it real-time where the system detects a weed and immediately triggers something to take it out on the spot?
Guy Coleman: It’s a lowercase "see and spray," so everything happens in real time.
Right now, it runs at about 60 frames per second on the Raspberry Pi 5. The system connects to a global shutter camera, I’ve got about 20 of them lying next to me here. The camera captures images and sends them back to a green detection algorithm. That algorithm assigns a coordinate along the X and Y axes for where the green is detected.
Once it finds the coordinate, it activates a GPIO pin, the general-purpose input/output pin, on the Pi. That pin then triggers a MOSFET, sending a high or low signal. The MOSFET controls the 12-volt line, which fires the solenoid to spray at that point. So it’s a completely closed system. Each OWL unit, by default, controls four solenoids or four outputs.
But we recently built one that controls 16 outputs. It’s actually a simple change, you just adjust the number of nozzles or relays and redefine which GPIO pins are being used. Once you do that, you can scale up and do basic section control across more nozzles.
Rhishi Pethe: But wouldn’t you need ISO integration for that? Could you actually install the OpenWeedLocator on a big machine, like a 120-foot sprayer? Could it work on a system that size?
Guy Coleman: If you add a whole new row of solenoids, then yes, you can expand it. Or you could tap into the 12-volt on/off signals that exist on ISOBUS systems. But honestly, for existing ISOBUS setups, it’s probably not advisable to use OpenWeedLocator directly, unless you’re willing to build a whole new setup. Basically, companies like TeeJet and others sell 12-volt solenoids, and you can attach those to the OWL. The OWL triggers them to turn on when it detects a weed.
But for that to work, you’d have to build a whole new boom with individual nozzle control that isn’t tied into ISOBUS. You’re effectively running a separate system. Now, if OWL were fully integrated with ISOBUS, which is the standard for most modern systems, then you could actually start tapping into existing nozzle control on a 48-meter boom or whatever size system you’re running. That would make integration into big setups much cleaner and more efficient.
At the end of the day, it’s just a matter of signaling. And I won’t pretend to be an expert on ISOBUS, but it can be done.
Scaling OWL
Rhishi Pethe: If someone gave you the funding, you and a team could potentially build that ISOBUS bridge and make it open source, right? Do you see the lack of that integration as a barrier to wider adoption?
What some people see as a defect is actually a feature, but for a certain group of growers, having that integration might make a real difference. Do you think building it would lead to higher adoption of OWL?
Guy Coleman: I think so. If you look at the American farm market, about 80% of the land is controlled by just 20% of the farms. That upper end of the market, the big operations, they’re the ones who would only adopt something like OWL if it were ISOBUS integrated.
I’ve spoken with farms that are buying million-dollar machines, and when they ask about OWL, I have to tell them, "No, it’s not ready for that kind of setup yet." So right now, those bigger farms, the ones who might actually be interested, are effectively excluded.
Expanding market access by adding ISOBUS integration would make a lot of sense. It would open OWL up to those larger operations and make integration much easier overall.
Rhishi Pethe: Are there other areas in agriculture where you think open source could also be a good fit? We’ve talked about AgOpenGPS, FarmOS, the Open Ag Data Alliance, they’re all trying different things. From the outside, it looks like AgOpenGPS has done a reasonable job pushing things forward.
Where else do you see opportunities for open source, especially in areas where you could give people a strong base version, and they could adapt it to fit their local niche? Because it sounds like that flexibility is a big driver for why you believe open source makes sense.
Guy Coleman: I think the big opportunities are all around vision systems, areas where you need to collect data, train a model, and then deploy it. Things like trunk size detection or insect detection stand out. That’s a really clear opportunity, just like OWL is for weeds, but for different use cases.
There are already some examples out there. For instance, open-source insect traps and a few more research-based tools. And on the software development side, there’s some interesting work happening at UC Davis, like AgML, where they're trying to create an open-source pipeline for training models. What would be really nice is seeing that pipeline extend all the way through to deployment on real farms, on real systems.
Another big area is data interoperability platforms. Leaf is one example, I’m not super familiar with them, but they’re doing interesting work. There are also efforts happening in Australia. I think there’s a real need for more open-source ways to integrate agricultural data, or at least expose APIs so other developers can start building off a common framework.
I always find it odd that with a lot of these data interoperability startups, you have to pay first before you even see how they’re making things interoperable. To me, the obvious thing would be to share your API and basic framework upfront. That way, developers can start building right away. For example, if I had access to their API documentation, I could integrate it with OWL almost immediately.
So I think that’s a really clear opportunity too. And probably the final area I’d highlight is robotics. You don’t necessarily have to give away everything, how you manage your hydraulic motors, battery systems, or internal sensors. But you could share how to steer the tractor, for example. Just make it a simple Python API, "if this, go left," "if that, go forward", and suddenly, someone could build a whole layer on top of your machine, like integrating OWL or other tools.
SwarmFarm is starting to do this with their SwarmConnect system. Farm-ng is another example. I’m sure there are more out there, but I think it’s a really smart approach. You’re not giving away your entire business, but you’re making it easier for people to innovate with your platform.
Honestly, it just makes business sense. People are still buying the robots, but now it’s easier to work with them, and it opens up more use cases. You can even see it with things like Spot, the robot dog from Boston Dynamics. They have a really clean Python framework for working with Spot.
And just this weekend, I came across a neat little game where you practice coding a drone to fly over a field and harvest crops. It’s all about creating high-level APIs, simple tools that let people control powerful machines without needing to be hardcore engineers.
And I think there’s a huge opportunity there in agriculture.
Rhishi Pethe: I’m hopeful that what people are calling “vibe coding”, with all these new LLM-based tools, might make it easier to build up the open-source community we’ve been talking about. I’m hoping it gives a real boost, not just for OWL but for other open-source projects too.
OWL has a hardware component. Raspberry Pi, and hardware evolves quickly. What do you think about keeping OWL up to date as hardware changes? For example, someone might build on a Raspberry Pi 3, someone else might use a completely different board. Pretty soon, you could end up with 50 different hardware versions out there. How do you manage that so people can still support and maintain what they’ve built?
Guy Coleman: The first thing I think about is version control, and just managing changes in hardware. That’s definitely a challenge in open source.
A lot of my time is spent dealing with things like that. For example, if you go to the OpenWeedLocator repository and look at the video manager file, it’s basically a whole bunch of classes that deal with different versions of picamera or different camera models people might connect. There’s just so much variety in what Raspberry Pi supports.
That’s actually one of the reasons I stuck with the Raspberry Pi ecosystem, it’s relatively stable. Most Raspberry Pi cameras work natively with OWL without too much extra effort. But even then, random bugs still come up. Like about a year ago, there was a kernel update that, for no clear reason, switched the image color channel ordering from RGB to BGR. It took me a long time to debug that.
There are definitely a lot of challenges when you’re working in this open space. And there are better ways to manage it, especially with stronger version control systems, which I’ll admit I probably haven’t done as well as I could.
On the flip side though, open source lets you capitalize much faster on improvements in hardware and software than a closed system would. If you're buying from a big OEM, they have to lock into a development path, commit to it, roll it out, and then support it for years. It slows things down. But if a new Raspberry Pi AI camera drops next month, someone working with OWL could start implementing it in a matter of weeks. So in some ways, it's both a blessing and a curse. It’s messy sometimes, but it also makes the system a lot more agile.
Rhishi Pethe: There’s definitely more risk when you build on something brand new. Even something simple, like an RGB-to-BGR switch, can throw everything off, and you’re left wondering what went wrong. Whereas if you buy from a company, you’re getting something that’s been fully tested, you know exactly what you’re getting. It’s a tradeoff, for sure. That makes sense.
How do you measure whether OWL is moving in the right direction? What are the dimensions you look at?
Guy Coleman: I guess I measure progress through a few lenses: adoption, performance, and ease of use, how easy it is for people to build or run the system. And honestly, it’s been really nice to see progress across all three.
Of course, it’s not moving as fast as it would if this were a startup where you just push everything out in six months or a year. But I actually like seeing it grow organically, from country to country. Right now, OWL is being built in about 10 or 12 different countries. And sure, it’s not happening at a massive scale yet. But honestly, how many spot-spraying companies can say they’ve expanded to a dozen countries in their first year? Not many.
And that's what’s exciting to me. It’s not just staying in one place, it’s genuinely spreading across every continent. What’s even better is that it’s making this technology accessible to people who might not otherwise have access. For example, if a global shutter camera is too expensive, someone can swap in a cheaper V2 camera that works better for their environment. That kind of flexibility is a huge part of why I’m so excited about open source in agriculture.
Of course, I’m always checking the GitHub stats, and some days it feels like nothing’s moving. But when you step back and really look at it, the progress is there.
Then there’s the technical side. When I look back at the initial commits, it's fascinating. My early code was so inefficient, we were running at 15 or 16 frames per second. Now we're hitting 60 frames per second. Sure, part of that is better hardware, the Raspberry Pi 5 is faster, but it’s also the code itself. I’ve moved from slow, inefficient loops to proper matrix operations, making everything much more compact and efficient.
And that’s exciting too, seeing the system become better not just externally, but internally as well. There’s a lot more planned. One big goal is incorporating green-on-green detection in a really streamlined way. I want to make it super straightforward: download public datasets from our open platform, train a model, deploy it on OWL, and create a circular open-source ecosystem that’s easy for anyone to build with.
That’s definitely a big part of where we’re heading.
Rhishi Pethe: Thank you Guy for joining the conversation!