With a name inspired by the great cellist Yo-Yo Ma’s appraisal of the complexity of blending bluegrass and classical music, the organizers behind GOAT, or the Gathering for Open Agricultural Technology, recognize the unusual challenge of cultivating a community of farmers, hackers, tinkerers and software developers to collaborate on open source hardware and software to increase transparency in the food chain.

A year after their first gathering in May 2018, the group has launched a web series, published reports around their goals, and is now actively seeking like-minded collaborators to work out a long-term roadmap while trial testing new ideas and products through their online community forums at goatech.org. Following up a moderated conversation on tools for collaboration at the inaugural Slow Tools Conference hosted at the Stone Barns Center for Food and Agriculture, we chat with two of GOAT’s founding organizers, Dorn Cox, research director at Wolfe’s Neck Center in Maine, and Ankita Raturi, researcher and incoming faculty member at Purdue for agricultural informatics about sensing with data, tools for collaboration and the democratization of technology.

Let’s start at the beginning—what were the seeds of GOAT? As founding organizers, how did this conversation begin and why?

Dorn Cox: Early on, we had a number of conversations around the Farm Hack community with some of the software and hardware technologists that were working on farm deployment of open source technology, as well as with a number of other technologists involved with the Farm OS platform. Often, working in technology and agriculture, we’re moderating our conversation for a broad or a general audience. We felt that GOAT was important to create a community where we, instead of working to explain every acronym, could dive deep, have fun and see where we could create and cross-pollinate across the ecosystem of open source technologies.

Who comprises this community?

Ankita Raturi: We’re a fairly mixed bunch and in these early days, we’re really just trying to find each other. The first GOAT really drew a mixed bag of folks: farmers who had been building stuff for themselves, researchers like me who are looking for other people interested in open source ag and tech, non-profits and industry (because there are folks building commercial applications on top of open source packages). In that sense, it’s like any open source community with users, developers and documenters who share an aligned set of values around what it means to build software, put it out into the world, and identify what form that could and should take.

DC: Early on we put a call out to the world to apply to be part of that first meeting. We based a lot of that structure on another open source community called GOSH, the Gathering for Open Science Hardware. They started in CERN, the European Organization for Nuclear Research, and then had their second annual meeting in Santiago, Chile, to recognize that there was real strength in diversity in an open source movement. It’s not just “nice” to have diversity but really necessary—we need the technology and the science behind it to be representative of the general population. Applying the same concept, agriculture should be a shared human endeavor that looks like the general population and welcomes everybody.

That actually brings me to my next question: you’ve mentioned some of your predecessors, including Farm OS, Farm Hack and GOSH. What are some of the key tenets you learned from previous communities that you wanted to bring into GOAT?

DC: As Ankita notes, one of the core things is that collaboration is really fun. This sentiment is fundamental and important because the authentic community that it brings and the primary rewards for participation is not always directly monetary. Research and development along those lines has infectious enthusiasm, and that’s important for the whole system.

Another key is that it has to maintain, regardless of the scale, a core of user-generated governance. When any one organization takes on too large a role, a community tends to atrophy. One of the difficult aspects of large open source projects is to have enough backbone support for the real-world organizing, but not have it be dominated by an academic governance or nonprofit organization. That’s one of the great challenges of these projects and why it’s important for the hard work to be engaging and fun at its core.

Besides the webinars that you have recently launched, what other backbone pieces are you building out to support the community?

DC: It’s a combination of the in-person work we do in that sort of unconference structure and taking that same approach to our online community. We use our discourse forum, online chat and the process of building collaborative documents to support our organic planning process for the future.

AR: If you look at many open source communities, oftentimes the users are also contributors to the projects whether as developers, designers, documenters, sponsors, etc. So you end up with a highly participatory approach where there’s no delineation between user and contributor. It’s important for us to “eat our own dog food” because if we’re not going to use the tools that we’re building, how can we expect anybody else to? It means that we end up user testing each other’s tools to try and break and make them better. Riffing off of that is this modular approach to a community: anyone can take ownership of pieces of it. We’ve had two hackathons since the last GOAT, and both were organized by different members.

Since the first GOAT gathering in 2018, what are some pockets of activity that are happening within the GOAT community?

AR: A couple of broad areas would be, one, figuring out how to support ag research. Particularly participatory research where you’re inviting farmers with real farm data to the table. There’s a lot of interest in creating a modular, reconfigurable, research data pipeline, especially because there’s all these different components that require us to do sensing on farms.

That leads us to thinking about the human experience, the user experience, of ag tech which has not always been given a front seat. But as we begin to bring farmers, scientists and other folks into our communities, usability and usefulness are now front-and-center discussions.

DC: I couldn’t do my agriculture or research work without interacting with the GOAT and other open source communities. [Building] knowledge around intensive, regenerative agriculture and adaptive management requires observation, analysis and communication that is beyond the capacity of any individual farmer to produce in a lifetime (soil science, circuit design, hydrology, biogeochemistry, fluid dynamics, mechanical engineering, software engineering, animal behavior… the list goes on), but it can be accessed rapidly through tech-facilitated collaboration.

I really like this idea that connective knowledge is what makes managing that complexity possible, and agricultural systems are nothing if not one of the most complex systems we can possibly be managing—especially if we’re trying to do it in a regenerative way. By sharing to improve our tools and practices instead of just learning from our own experiences, we have the benefit of rapidly compounding thousands of seasons and experiences.

In order to achieve wide-scale adoption of this really complex biological agriculture, the idea is that the more we know, the less we actually need in the field: so it’s shrinking global knowledge down to something that’s practical. In that quest, we interact with this collaborative community every day, all the time. There are very few aspects of how I currently practice agriculture that are not informed by this collaborative design process. GOAT and FarmHack are a reflection of that process.

That drives to the heart of the importance of building tools (physical and digital) that can be shared and adopted across global geographies and applied to local contexts. Much of current ag tech builds on data being collected through computer sensing hardware that measures things like soil and plant health, climate volatility and external stressors. Is it important for this information to be accessible to the public, and how can the complexity of this type of data help farmers working within a local context?

AR: It’s not necessary that all data should be accessible to the public. “Sharing” is a cultural phenomenon that we can support through tech, not necessarily enforce. No one is entitled to anybody else’s data because there are privacy and ethics concerns. Instead, I would argue we need openness in the way in which data is collected. If we’re developing a sensing hardware for farmers, gardeners, eaters or researchers, they should be able to look under the hood and understand how that data is collected or sensed, structured and conveyed. You’re basically giving humans agency over data to choose, do I want to share this? Is it appropriate? How do I want to share this?

DC: I would add to that: agency over data that we’re producing on our own farms is really important because that is valuable. And that’s a really important contribution from farmers. It’s not just about the food we’re producing, but also all the other environmental services and observations about how the world works.

Publicly funded tools and publicly funded datasets that represent our best understanding of science are an exception. There are aspects of the agricultural system that should be in the commons, and those are key things, like the way in which we talk about plant species, weather data, climate data and soil data.

The argument to use data toward precision agriculture and greater mechanization can be flipped on its head as we democratize access to these tools—away from precision ag and more toward decision ag. How do we use the best available information to make better decisions, whether that’s automated or with our own hands? That’s a different way of thinking about technology and the environment, making the technology disappear rather than dominate the environment—making technology more invisible while the natural world becomes more visible.

AR: Thinking about this through a resilience lens, one way of increasing resiliency is through a distributed approach to systems building or by creating networks in which people share things. By making available tools that allow people to share granular data or by making available ancillary data sets through open access—that’s the soil and weather data—you can now start to enable people to do things like reflect and improve on their own systems, the network of systems, and things like sustainable resource management.

My last question comes to a line that Dorn mentioned in our conversation at the Slow Tools Conference. He said we should be building these systems with outcomes we have in mind that reflect a new set of values. What do the specifics of this new set of values look like for a community interested in creating open access and more agency around data?

AR: We have come to some consensus on things that we believe in, but we are still forming [them]. The GOAT report was a summary of the things that we know we need to do. So we know that we lack certain kinds of technical support. There’s a lack of awareness around what ag technologies are already open source or who is interested in open access to data. We need governance and funding. We need to reduce duplication efforts. We want to increase interoperability among our data and tools, and figure out better ways to structure and share data.

So now we’re beginning to think of how we can now start to articulate our shared philosophy. Overall we’re generally interested in producing technologies that enable folks to have agency over their data and be able to reflect on the performance of their farms.

DC: That by itself is significant because what I was referencing was the idea that artifacts and tools are political by their very nature. A $60,000 spectrometer represents a certain political assumption about who does research and who has access to critical knowledge about how the world works. Are we essentially building barriers? It’s possible for everybody to have access to that technology. It’s a decision that we’re making.

AR: Specific ways in which we’re trying to work toward democratization of technology include talking more openly about interoperability. We are all in agreement that we need modular architectures in the design of software. We also need to take a more human-centered approach to the design of our tools by taking a participatory approach with the users, the technologists and vice versa.