The John Deere Affaire

Many of those with a passing interest in agriculture or technology will have heard of The John Deere Affaire, where John Deere has sued its customers, claiming that they don't actually own the tractors that they've purchased, but rather hold "an implied license for the life of the vehicle to operate the vehicle." This is probably news to the farmer who bought it.

Now, this is a particularly vulgar example of a dynamic that is happening across the various attempts to "techify" agriculture. Companies are attempting to replicate in farming what has been a successful model in the consumer internet, namely providing services in lieu of products. While the John Deere example is particularly egregious, many of the big players are trying to get farmers to pay them for the honor of collecting data on their behalf. Sound familiar?

Precision agriculture is vitally important, but I contend that trying to build the Facebook of Corn is ill-fated. Customers (farmers) want to be able to fix their tools and they want to own their data. What they really need is decentralized precision agriculture.

What a Farmer Really Wants (I've Heard)

Many people from the "tech" world who design for farmers labor under the misapprehension that all people who work with their hands are like the Home Depot Mascot, but the reality is far more nuanced.

A colleague once told me, speaking of fish farmers, that when you give a farmer a new piece of equipment, they'll learn to play it like a musical instrument. I found this to be a very evocative analogy. It means that, instead of designing for ease by making things simple, you should design for autonomy. Design for playability.

Practically, this means that a farmer needs to understand what a tool does. And they need to be able to fix it, debug it, tinker with it, etc.

Property rights are also extremely important to farmers, as their land and the tools that they use to work it are viewed as safeguards to their autonomy. This means that no farmer in his right mind will agree to the kind of arrangements that we consumers regularly submit to, namely that we don't own the data that we generate.

In concrete terms, this means that a farmer wants tools, not services and he wants to own his data.

We have the technology

Most precision agriculture products actually do think about themselves as the Facebook of Corn. They want to collect data from the farm, hoover it into a centralized computer facility (9 times out of 10 it's AWS) and then sell the insights from their analysis back to farmers. Since the software doesn't run on the farm, the farmer doesn't own it. It's very unclear if he even owns the data that his fields generate. It's like paying for a hammer every time you pound in a nail.

If you think that interoperability is a problem on the consumer internet, let me tell you about the disaster that is the "smart tractor." The major tractor brands: Case, Deere, Kubota, etc. all have proprietary operating systems. Creating something as simple as a USB dongle that downloads your planting data requires a developer to design against several systems that are mutually incompatible.

The barriers to both fixability and ownership are not simply "corporate malevolence," they are based on technical realities. In the following, I will talk about the technical roots of these problems and existing or near-existing technologies that can help us find our way around these problems.

Urbit

Urbit is a clean-slate operating system that is natively networked and runs without system calls, making it easily installable on any Unix-y platform. Perhaps most compelling is the ability for an instance of Urbit to spawn child Urbits which are automatically networked to the parent and which are functionally the same. An analogy might be if, every time you got a new phone, you could just clone your computer's OS and run it on the phone; each able to network with the other.

In a precision agriculture application, this means that a farmer could have one Urbit instance running in his workshop. When he wants to add a new water sensor, he spawns a new Urbit to run the sensor. The sensor will be addressable from the parent Urbit and can easily be debugged with the same tools that the farmer uses on his home Urbit. We could do the same thing for a tractor, for an irrigation system, etc.

Since each of these devices is federated, but self-sufficient, it means that they are ideally suited to an imperfectly connected environment. If the farm's connection to farmcorp.com goes down, it won't matter, since the devices on the network are perfectly capable of chugging along on their own. The tractor can be lent to a friend for a week and come back, no worse for the wear.

While John Deere suing its customers to prevent them from tinkering with their devices is a particularly gross example, it is not rooted 100% in corporate malevolence. These devices are indeed complex and, frankly, the software systems are not designed for self-service; it is exceedingly hard to make these fiddly 70's technologies like Unix and TCP do what we want them to do in the comfort of our air-conditioned offices, much less out in the sun and the dirt.

Urbit is not simple, but we can imagine building agriculture-specific layer on top of Urbit that would, indeed, allow farmers to learn to play it like a musical instrument. I would also argue that, while Urbit may be complex, learning how to interact with it once would, in my above example, allow a farmer to debug and fix his sensors, his tractor and his irrigation system, instead of learning how to do all of these things independently.

IPFS

The torrent of data produced by modern tractors and and sensors has to go somewhere, and very few farmers have data centers out on the field. Even if they got the urge, network infrastructure is not favorably sited outside of large cities, making the idea of uploading all of one's own data to the cloud infeasible.

Enter IPFS or the InterPlanetary File System. IPFS can best be understood as a BitTorrent-esque file system that allows data to be broken apart and stored on several machines. Instead of one large data center, there would be data stuffed into every spare corner of the machines nearest you, allowing you to access the data without even connecting to the broader network.

This would remove the technical hurdles to a farmer hosting his own data, and perhaps the data for nearby farmers. Local farmers co-ops, which already exist, could even host their own mini-data centers using IPFS. A farmer’s co-op with a drone and an IPFS-based data center could offer its members many of the benefits of overhead imaging-based precision ag techniques without waiting for high-connectivity networks in rural regions.

The Apocalyptic Part

The argument against monoculture in agriculture is quite clear: If you only farm one crop, you open yourself up to a single blight or drought leading to not only loss of money, but famine and death. In short, you make yourself very fragile.

As it goes for crops, so it goes for technology.

One of the visions of AgTech boils down to “farming as a service.” A future where there is a tractor as a service, seeds as a service, weather prediction as a service, etc.

Can we honestly to believe that these services will somehow be more secure or long-lasting than those that have come before it? The recent spate of ransomware attacks on large corporations speaks to the contrary.

Can you imagine the carnage, both literal and figurative, that would arise if a service upon which a significant number of farmers rely goes out? It wouldn't even have to be hacked, it could just go down. It could simply be bought and shuttered by a competitor and throw an entire operation into disarray.

In order to make farming more efficient, we should embrace precision agriculture.
In order to preserve the livelihood of farmers and build a robust food system, that precision agriculture needs to be decentralized.