OpenSourceAg #2 - The AgTech Paradox: Restaurants vs. Recipe Books

How do restaurants and recipe books coexist?

If you take an agtech lens to the culinary world, one possible conclusion is that recipe books pose a threat to the operation and success of restaurants. One might think that investment in new recipe books would undermine restaurant operations—a paradox? Maybe an overstatement. Yet, the food service industry, valued at approx. US$3.2 trillion coexists with the approx. US$7.5 billion cookbook market, generally about 20 million books sold annually (Note: there does not seem to be exceptionally trustworthy cookbook market analysis, so take these figures with a pinch of salt). So for two editions in a row, let’s explore the recipe book-open source analogy.

Welcome

Welcome to the second edition of the OpenSourceAg newsletter. In here I’ll expand on this recipe book analogy a little further and dig through the repositories of agtech players both large and small. Plus, there has been some really interesting work published of late—neural networks that adapt to what they see, a great presentation by Steven Mirsky of the USDA on the importance of open-source image data and the concept of ‘field observation intensity’. There are also some great updates on a 4m wide OWL system developed in NSW, Australia by Pat Hulme.

Thanks for being part of this newsletter—I really enjoyed all your comments and feedback after the first edition. So please keep them coming, and get in touch if you see anything of interest or have ideas you’d like to share.

Table of Contents

• How do restaurants and recipe books coexist?

• Exploring recipe books and agtech

• OpenWeedLocator Updates

• Interesting Reads

  • Dynamic Neural Networks (DyNN) for efficient model …

  • Open-source imagery

  • Field observation intensity

• Final Thoughts

Exploring recipe books and agtech

The reality in food is that these two products—food service and DIY food—occupy substantially different market segments. I profess no real understanding of the restaurant world, so I’ll speak only from experience—food-to-order is a treat and my mantra is I’ll generally only order something if I couldn’t make it myself at the same standard. I’ll visit a restaurant or order take away because it offers better quality, experience, convenience and taste.

And so recipe books and restaurants share a happy existence—famous chefs from famous restaurants (e.g. Anthony Bourdain from Les Halles) deliberately sharing their insights on common recipes (though perhaps not all their kitchen secrets) because they know it will diversify their market base and cement their reputation and influence on the industry. Gordon Ramsay set a standard for relatively replicable and delicious scrambled eggs in the home that would not have been achieved if it weren’t for his books and videos demonstrating how it’s done. The added bonus is it helps young chefs, food innovators and new restaurants lift their game from the outset.

So how does this relate to agtech? Well the famous restauranteurs of the world are the likes of John Deere, CNH, AGCO, Kubota, Claas and Mahindra among all other large manufacturers. Logically, these multi billion dollar companies would have released recipe books, APIs for their equipment and datasets right? Right?

The reality is unfortunately, no. Github is broadly speaking the most widely used place for sharing and contributing to open source tools through code, version control, documentation and public review. So it’s a good yardstick for how willing a company is to support the community. Walmart has a relatively active presence through Walmart Labs for example, besides the major tech companies of Meta, Google, Amazon of course. So using Github as an indicator of ag companies’ code-sharing presence, the results are quite disappointing. The ‘Last Active’ column is only indicative of recent activity and relative to the time of writing.

While it may be expected that these large companies have little to no specific agricultural presence (Bayer/Trimble are very broad companies), the trend is shared with startups. As a resource constrained business competing with large companies, clearly, publishing all your secrets is unwise. It requires confidence in your moat.

Browsing these repositories you can learn some neat things about companies—Solinftec forked YOLOv5 a couple of years ago (do they use off the shelf algorithms?), and Carbon Bee mention some of the CTIS imaging work behind their system as two examples. The approach is quite innovative (although I am yet to see side-by-side comparisons with other companies), and it goes beyond the RGB imaging of most other companies (and the OWL) that are involved with weed detection for targeted application.

In any case, the trend in agtech from the big and small players is a low interest (at least in this manner) in building publicly and contributing back to the same communities that have allowed them to grow. Fortunately, there are many precision ag enthusiasts, farmers, researchers and other innovators and startups that are filling in this space. You can keep up to date on some of these over on the OpenSourceAg repository.

But what is the incentive? What about the competitive advantage? Besides altruism, why should anyone publish their own code, data, protocols for others to use? Perhaps the analogy falls down—recipe books bring a clear revenue stream, though 426x smaller than the food service business. Open-sourcing code doesn’t have any tangible financial benefit, or so it seems.

Except I disagree with this argument—I believe that there are benefits for companies big and small in this space that don’t erode competitive advantage, when conducted strategically. Some of these are articulated in the previous issue with the “7 advantages of open source development”, though this focused more on the scientific and less on business.

So for a more business focused series of potential advantages, here are four examples.

1. Accelerated innovation from collaboration beyond the existing talent pool

2. Establish market leadership through setting of industry standards (more difficult for smaller companies without the large market footprint)

3. Enable expansion into more niches within agriculture by reducing barriers to entry. For example, charge for add-ons, premium packages and support, but share the base recipe.

4. Build partnerships more organically by allowing others to build on your equipment/tools. SwarmFarm is a good example here with SwarmConnect. Farm-ng have also opened their API for interoperability and development.

As with anything, strategy is key. Building a recipe book that benefits everyone is possible, without giving out your secrets for no added advantage. This isn’t business of financial advice, just my opinions—so be careful with your own approach here and seek the advice of professionals in this space. Strategy is also doing a lot of heavy lifting here, I’ll explore this in future editions.

OpenWeedLocator Updates

As a DIY system the an OWL setup can take on many different forms. This version is from Pat Hulme in NSW, who developed a 4m wide trailed sprayer using the original OWL enclosures, a Raspberry Pi HQ Camera and Goyen solenoids. It’s towed by a UTV for targeted application around the farm.

A video of the system in action is available via Bluesky below. If you’re interested in building something similar yourself, I’d recommend going through this list for parts we used on a 2m vehicle-mounted system. Upgrading to the Global Shutter camera, Raspberry Pi 5 and OWL Driver Board with MOSFETs instead of electromechanical relays will improve the response time as well.

Pat sent the photos with a few bits of feedback about the system.

If you’re interested in some other builds, be sure to check out the Community Builds page on the OWL repository.

Interesting Reads

1. We’ve been dumbed-down’: Australian farmers want the right to repair their own tractors again | The Guardian

   I will dive into the Right to Repair in future issues, but this article is good perspective on the topic. It goes hand in hand with open-source development and the recipe book analogy.

2. Which kind of innovation is right for you? | Pisano & Verganti, Harvard Business Review

   This article provides a really nice overview of how different approaches to innovation and each level of openness fit in different business cases. Well worth a read.

Dynamic Neural Networks (DyNN) for efficient models

Running more complex weed recognition models on devices with limited computing capacity (otherwise known as edge devices, e.g. Raspberry Pi or NVIDIA’s Jetson series) means a large body of research is dedicated towards algorithm efficiency. A typical trained convolutional neural network takes in an image, runs it through the entire algorithm and comes up with some prediction at the end—e.g. 91% confident this is fleabane (Conyza bonariensis). But logically, there are some really obvious fleabane plants and some fleabane that look more like something else. So what if we didn’t waste our efforts so much on the obvious examples?

Enter dynamic neural networks (DyNN). I learnt about this body of research only very recently, so the above explanation is certainly oversimplified, but the concept is fascinating. The interest was spurred by a recent survey of the topic from some colleagues at the Danish Technical University (Ronja Guldenring and Lazaros Nalpantidis), who work in precision agricultural robotics. There is an accompanying Github repository with links to all surveyed papers and relevant implementations.

One DyNN early exit approach referenced in the survey adopts an architecture that adapts resolution required through the network, using coarse features where acceptable.

From our research on multi-growth stage weed detection, this would be particularly helpful for small weed detection, where large weeds were fairly consistently detected even at low resolution (high on-ground pixel width). Similarly, the combination of both digital images (RGB data) and depth or other data format (known as sensor fusion) could be quite applicable here. Humans don’t always need depth information when decision making, but a pair of eyes is very useful for depth estimation through stereovision when needed to navigate complex environments. We unfortunately did not evolve lidar nor sonar.

Open-source imagery

Dr. Steven Mirsky is an ecologist with the USDA, working on the (very) large scale collection of weed image training data. Mirsky co-founded the Precision Sustainable Ag (PSA) network and Get Rid of Weeds (GROW) platform and helps run this large scale dataset collection project. He recently gave a fantastic presentation for a USDA-ARS series on the value of open-source data. Well worth watching.

Field observation intensity

One interesting concept mentioned by Mirsky is that the growth in average farm size led to overly large management units—a substantial loss of precision with fewer eyes on each unit area. Precision agriculture is now making up for this deficit by replacing human eyes and decision making with large scale sensing from satellites, drones and ground-based platforms.

It’s a concept I’ve been considering recently after speaking with a farmer in Australia. The farmer mentioned his grand parents, who had cleared the land, would specifically avoid certain areas based on the remnant vegetation. Yet over time these areas had been cleared to simplify management practices with large machinery. For him, precision agriculture was replacing that inherited knowledge with digital observations. Another example is hand weeding—exceptionally labour intensive and difficult over large scales, so there is incentive to only control those weeds that are most impactful. Nothing specific to point to here to read, besides Mirsky’s presentation.

Final Thoughts

The world of Large Language Models (LLMs) was thrown into a spin by the release of the DeepSeek-V3 models. It is supposedly more efficient yet about as effective as other existing models from OpenAI, Meta, Anthropic and others. Importantly, it’s open-source and MIT licensed, so you can read how they built the system from the paper they released. The model weights have been released on HuggingFace, with instructions on how to operate them locally. It’s a big shift for the industry—which had largely existed with moats around compute quantity, based on the assumption these models were only trainable with extraordinary numbers of GPUs. If the DeepSeek claims around training requirements are true, then that hardware/capital moat has been severely reduced.

It raises questions for agtech—is a transformational moment like this possible in agriculture through open-source releases? Can and should we evaporate moats if it betters the industry but disrupts the status quo?

If you like this newsletter, please share it around and subscribe. Until the next edition!

Cheers,
Guy