<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://www.runrig.org</id>
    <title>The Runrig Plan</title>
    <updated>2025-11-01T16:22:39.414Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <author>
        <name>The Runrig Team</name>
        <email>jamie@runrig.org</email>
        <uri>https://www.runrig.org/about</uri>
    </author>
    <link rel="alternate" href="https://www.runrig.org"/>
    <link rel="self" href="https://www.runrig.org/feed/atom.xml"/>
    <subtitle>All bi-weekly publications from Runrig, including The Runrig Plan, The Runrig Journal, and Technical Reports</subtitle>
    <logo>https://www.runrig.org/open_field_system_all_600x745_bg_light.png</logo>
    <icon>https://www.runrig.org/emoji_u1f69c.svg</icon>
    <rights>Except where otherwise noted, content on this site is licensed by its authors under CC BY-SA 4.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/4.0/ .</rights>
    <entry>
        <title type="html"><![CDATA[Consulting on Farm Flow]]></title>
        <id>https://www.runrig.org/farm-flow.html</id>
        <link href="https://www.runrig.org/farm-flow.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2025-05-26T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Project profile for Runrig's role consulting on the Farm Flow app designed & created by Fitzgerald Organics.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Consulting on Farm Flow</h1><p><strong>A Runrig Pilot Project</strong></p></header><div style="position:relative;" class="vp-doc _farm-flow" data-v-e6f2a212=""><div><p><img src="https://www.runrig.org/whiteboard_2024-06-09-a.jpg" alt="" title="The original Farm Flow whiteboard"></p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="https://www.runrig.org/farm-flow.html#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Farm Flow is a comprehensive suite of farm management tools, comprising two main parts: the <strong>Farm Flow Board</strong> and <strong>Farm Flow SOPs</strong> (standard operating procedures). The board is the central visualization, with a sweepingly full view of the season's crop plan, field actions, and significant weather events. All the critical data points on the board correspond to criteria and prescriptions detailed in the SOPs, which are based on a formal data analysis of real-world organic farming practices and the outcomes they produce. With these utilities in hand, team members can coordinate their activities to achieve targeted production volumes, desired costs savings, and positive environmental impacts. As a wider community and a forum for exchanging knowledge, Farm Flow also connects farmers to agronomists, technicians, designers, and other stakeholders, activating new channels for collaboration and innovation.</p><p>The system was designed and built by farmers, for farmers, principally Matthew Fitzgerald of Fitzgerald Organics in Minnesota. The canonical version is a physical whiteboard, which Matthew has replicated for several other farms in his region, offering a D.I.Y. Kit to anyone who thinks they may benefit from it.</p><p>See the <a href="https://www.tryfarmflow.com/" target="_blank" rel="noreferrer">official Farm Flow website</a> for the latest updates on the software project, its current status, and how to sign up to use the application or create your own physical Farm Flow whiteboard for your farm.</p><h3 id="the-pilot-app-development-strategy" tabindex="-1">The Pilot App &amp; Development Strategy <a class="header-anchor" href="https://www.runrig.org/farm-flow.html#the-pilot-app-development-strategy" aria-label="Permalink to &quot;The Pilot App &amp; Development Strategy&quot;">​</a></h3><p>Runrig's primary role was to steward the project from its physical form to the digital realm.</p><ul><li><a href="https://www.runrig.org/posts/farm-flow-backstory.html">Project Backstory &amp; Initial Assessment</a></li><li><a href="https://www.runrig.org/posts/farm-flow-pilot.html">Pilot Application &amp; Portable Data Architecture</a></li><li><a href="https://www.runrig.org/posts/farm-flow-strategy.html">Continued Development Strategy &amp; Recommendations</a></li></ul><h2 id="additional-information-resources" tabindex="-1">Additional Information &amp; Resources <a class="header-anchor" href="https://www.runrig.org/farm-flow.html#additional-information-resources" aria-label="Permalink to &quot;Additional Information &amp; Resources&quot;">​</a></h2><h3 id="project-sponsors" tabindex="-1">Project Sponsors <a class="header-anchor" href="https://www.runrig.org/farm-flow.html#project-sponsors" aria-label="Permalink to &quot;Project Sponsors&quot;">​</a></h3><ul><li><a href="https://madagriculture.org/journal/meet-a-mad-farmer-fitzgerald-organics" target="_blank" rel="noreferrer">Mad Agriculture</a></li><li><a href="https://11thhourproject.org/" target="_blank" rel="noreferrer">11th Hour Project</a></li></ul><h3 id="development-partners" tabindex="-1">Development Partners <a class="header-anchor" href="https://www.runrig.org/farm-flow.html#development-partners" aria-label="Permalink to &quot;Development Partners&quot;">​</a></h3><ul><li><a href="https://www.fitzgeraldorganics.net/" target="_blank" rel="noreferrer">Fitzgerald Organics</a></li><li><a href="https://www.cloudburststudio.com/" target="_blank" rel="noreferrer">Cloudburst</a></li><li><a href="https://www.runrig.org/" target="_blank" rel="noreferrer">Runrig</a></li></ul><h3 id="related-links" tabindex="-1">Related Links <a class="header-anchor" href="https://www.runrig.org/farm-flow.html#related-links" aria-label="Permalink to &quot;Related Links&quot;">​</a></h3><ul><li><a href="https://share.mayfirst.org/s/Bj5FknFttsib2LD" target="_blank" rel="noreferrer">Farm Flow Presentation</a> by M. Fitzgerald to the OpenTEAM HCD Working Group</li><li>The Mad Agriculture Journal: <a href="https://madagriculture.org/journal/meet-a-mad-farmer-fitzgerald-organics" target="_blank" rel="noreferrer">"Meet a Mad Farmer: Fitzgerald Organics"</a></li></ul></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Against Scale]]></title>
        <id>https://www.runrig.org/posts/against-scale.html</id>
        <link href="https://www.runrig.org/posts/against-scale.html"/>
        <link rel="enclosure" href="https://www.runrig.org/assets/ocean-trawler-attenborough-2025.BcF9LlhV.png" type="image/png"/>
        <updated>2025-08-29T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[A look at the way scalability perpetuates some of the worst tendencies of neoliberal capitalism, and how Runrig proposes to overturn those harmful dynamics through participatory design and transparent abstractions.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Against Scale</h1><p><strong>The cloud falling back down to earth</strong></p></header><div style="position:relative;" class="vp-doc _posts_against-scale" data-v-e6f2a212=""><div><p>At the end of my first round of consultations for the Farm Flow project, I submitted my recommendations for its <a href="https://www.runrig.org/posts/farm-flow-backstory.html#deciding-on-a-development-model">development model</a> with some closing remarks to make clear my own biases that led to those conclusions. I don't pretend to put all of my political convictions aside when rendering a professional opinion, but I do try to be transparent. Those remarks, under the final subheading of "Distributing Cost &amp; Control; Organizing Support &amp; Reach," read in part:</p><blockquote><p>I’m reluctant to speak in terms of “scaling” product development, as is common today in start-up culture and industry. [I find that scaling] is essentially at odds with the goal of producing technology that affords its users greater autonomy, both individually and collectively. I prefer to think about the ways technology can help to distribute control over our production systems, while also diffusing the costs of maintaining them. From this perspective, it’s not the product that expands to an ever greater and greater scale, but rather our capacity to organize a larger bloc of mutual support with a stronger commitment to shared values.</p><p>[...]</p><p>In terms of technology development and <em>especially technology maintenance</em>, widening the circle of cooperation can diffuse costs, by lowering the stakes required to initiate development at the very start, while also averaging out the long-term costs of ownership through shared ownership.</p></blockquote><p>Roughly 6 months later, I was putting together a <a href="https://dweb.camp/p/foodweb__response-to-utility-proposal" target="_blank" rel="noreferrer">critique</a> of two funding proposals that emerged from DWeb Camp 2024. I drew upon those early assessments, as well as lessons I took away from subsequent Farm Flow consultations, when I voiced my misgivings over certain aspects of those plans that adhered to conventional development models like scalability. Recycling language from the above remarks, I contrasted Runrig's proposed methods with what I saw as some of the worst practices of venture capitalism. I then tried to distill it down to one succinct table:</p><table tabindex="0"><thead><tr><th style="text-align:right;">Runrig Methodology</th><th></th><th style="text-align:left;">Venture Capitalism</th></tr></thead><tbody><tr><td style="text-align:right;"><strong><em>Distributing</em> CONTROL</strong></td><td>vs.</td><td style="text-align:left;"><em>Scaling PRODUCTION</em></td></tr><tr><td style="text-align:right;"><strong><em>Diffusing</em> COSTS</strong></td><td>vs.</td><td style="text-align:left;"><em>Accumulating CAPITAL</em></td></tr><tr><td style="text-align:right;"><strong><em>Expanding</em> PARTICIPATION</strong></td><td>vs.</td><td style="text-align:left;"><em>Consolidating MARKETS</em></td></tr><tr><td style="text-align:right;"><strong>WORKER-<em>organizing</em></strong></td><td>vs.</td><td style="text-align:left;"><em>RENT-seeking</em></td></tr></tbody></table><p>To be honest, I'm still quite ambivalent about the this framing. I'm not at all confident that each Runrig method correlates perfectly to its VC counterpart in a significant or illustrative way, but I do feel most confident on the point about scale. I almost think I could have filled in the entire right-hand column with "scaling" of one type or another, and each element in the left-hand column would still pose a distinct, valid alternative to some aspect of scalability. In a way, venture capitalism as a whole can be summed up rather bluntly as "scale everything, all the time," without much regard for the particulars.</p><p>More recently in my article on <a href="https://www.runrig.org/posts/illegible-agriculture.html">Illegible Agriculture</a>, I discussed how ag-tech startups have a penchant for oversimplifying the essential complexities of agriculture and regional food systems. I asserted that this is not meant to improve those systems at the community level, in accordance with users' unique needs and desires, or by taking into account local sensibilities. At the end of the day, these complex systems must be simplified in order to "render the labor, knowledge, and produce of that community more suitable for mass consumption and capital accumulation."</p><p>Scalability, then and now, is at the very top of my list of complexity-erasing strategies in today's tech industry that must be re-evaluated, and if no redeeming qualities are forthcoming, it ought to be jettisoned from our methodologies entirely. Likewise, in our discourse around software development it should be relegated to the set of anti-patterns found to be inimical to appropriate technology design.</p><h2 id="thumbs-on-the-scale" tabindex="-1">Thumbs on the Scale <a class="header-anchor" href="https://www.runrig.org/posts/against-scale.html#thumbs-on-the-scale" aria-label="Permalink to &quot;Thumbs on the Scale&quot;">​</a></h2><p>In Silicon Valley, there is a widespread fascination with scaling, or to be more precise, <em>digital technologies that scale</em>. The verb "to scale" in this context can take the passive voice, as in digital technologies that "can be scaled," or an active voice for technologies that facilitate "the scaling of" other systems. The other systems can be digital or non-digital, and if some new tech promises "to scale" and "to be scaled" at the same time, all the better. Many a would-be founder has exalted the properties of this or that technology for its ability to scale without being especially clear on what's being scaled, as if by some quasi-magical property latent in the computer chips to scale all they touch. But scaling is by no means inherent to the nature of computation, nor does scaling emerge from digital technology all of its own accord. Rather, I would argue, it is imposed on technology by a mandate from venture capital investors to pursue unlimited economic growth. As Karen Hao observes in <em>Empire of AI</em>:</p><blockquote><p>In the end, Moore’s Law was not based on some principle of physics. It was an economic and political observation that Moore made about the rate of progress that he could drive his company to achieve, and an economic and political choice that he made to follow it. When he did, Moore took the rest of the computer chip industry with him, as other companies realized it was the most competitive business strategy. OpenAI’s Law, or what the company would later replace with an even more fevered pursuit of so-called scaling laws, is exactly the same. It is not a natural phenomenon. It’s a self-fulfilling prophecy.</p></blockquote><p>Where information technology does make an original contribution is in its unrivaled capacity for <em>abstraction</em>, a power that can just as well be applied to scaling as to other unrelated tasks or even opposing aims. A well-designed computer algorithm can abstract away concrete details of the real world – e.g., material goods and services, users, workers, facial expressions, social relations, monetary costs, environmental costs, etc. – and whisk them away to the <em>cloud</em>. Once in this realm of pure abstraction, properties like color, size, and shape become mere numbers or bits. Free of all physical encumbrance, our worldly cares assume new virtual bodies, becoming weightless, untethered, and without consequence. Up there in the cloud, scale itself is only limited to the largest number you can fit into a <a href="https://tromp.github.io/blog/2023/11/24/largest-number" target="_blank" rel="noreferrer">64-bit register</a> – although that limit, too, can be easily abstracted away.</p><p>When the object of scaling is economic productivity or market dynamics, computational abstraction becomes an accelerant for capital's race towards infinite growth. This secret sauce – abstraction coupled to a business model meant for rapid market growth and capital accumulation – is what business analysts or techno-optimists typically infer by the neologism: <em>scalability</em>.</p><h2 id="the-physicality-of-information" tabindex="-1">The Physicality of Information <a class="header-anchor" href="https://www.runrig.org/posts/against-scale.html#the-physicality-of-information" aria-label="Permalink to &quot;The Physicality of Information&quot;">​</a></h2><p>To head off any criticism that I'm focusing exclusively the administrative dimensions of scale, I should acknowledge that there is, in fact, a scientific context in which "scalability" can denote a real-world quantity that can be measured empirically. It requires strict definitions of one's parameters and can be said to govern a specific range of phenomena under controlled conditions. That still doesn't make it a predictor of planet-wide industrial production cycles, subject to the whims of the global economy and the twists and turns of geopolitics. Yet even as academic terminology, "scalability" comes freighted with some heavy socioeconomic implications. Its physical limits and potentials, as measured in the laboratory, may have little predictive power over macroeconomic trends, but that's not to say influence doesn't pass the opposite direction, from Silicon Valley into the halls of the academy. That's what funds scientific research into scalability in the first place: it is significant principally as a managerial science for the Nasdaq-100.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/against-scale.html#fn1" id="fnref1">[1]</a></sup></p><p>It nevertheless remains to be seen if the abstractions of scalability can survive eventual contact with reality – <em>the cloud falling back down to earth</em>, so to speak. Computational abstractions do incur physical costs and real-world consequences, and there are practical limits to the scale of their application, even if they encompass theoretical infinities. The need for sane limits on computational scaling could not be more acute than in the face of our accelerating climate crisis and the rising number of geopolitical conflicts spawned by competition over finite energy and mineral resources. Indeed, such resources will never be adequate to the computational demands of today's tech moguls, if left to set their own limits. When Microsoft announces <a href="https://www.npr.org/2024/09/20/nx-s1-5120581/three-mile-island-nuclear-power-plant-microsoft-ai" target="_blank" rel="noreferrer">it will reopen Three Mile Island</a> to power its large language models, <em>this is the cloud falling back down to earth</em>. When companies like Apple, Tesla and Dell are willing to pay millions of dollars in legal fees each year so they can keep <a href="https://arstechnica.com/tech-policy/2024/03/apple-and-other-firms-dont-have-to-compensate-victims-of-forced-child-labor/" target="_blank" rel="noreferrer">extracting the conflict minerals</a> that power our smartphones, electric vehicles, and other devices, <em>this too is the cloud falling back down to earth</em>.</p><p>I need only to gesture slightly towards the current AI bubble and its <a href="https://ig.ft.com/ai-data-centres/" target="_blank" rel="noreferrer">impending burst</a>, as its hype finally seems to be fading and this terawatt-hour-expending project with its <a href="https://www.democracynow.org/2025/7/4/empire_of_ai_karen_hao_on" target="_blank" rel="noreferrer">"scale-at-all-cost"</a> approach, as Hao calls it, is exposed for the massive scam it has always been from the start.</p><h2 id="a-measure-of-social-control" tabindex="-1">A Measure of Social Control <a class="header-anchor" href="https://www.runrig.org/posts/against-scale.html#a-measure-of-social-control" aria-label="Permalink to &quot;A Measure of Social Control&quot;">​</a></h2><p>Beyond the clear perils to our planet's climate and natural ecosystems, rapid scaling also poses a dire threat to our social and cultural ecosystems. When big tech companies talk about scalability, they might have in mind scaling the production of material goods and services (e.g., GrubHub, Apple, Tesla), scaling the marketplace for those goods and services (e.g., Amazon, AdSense, Square), scaling cultural exchange and artistic expression (e.g., Netflix, Spotify, YouTube), or scaling the tenuous fibers of our social relations that get bound up in all of that (e.g., Facebook, LinkedIn, Tinder). When these processes are scaled by algorithmic abstraction, however, we find that some essential aspect – some inherent quality of our culture, of our social relations, of our very material well-being – always seems to get lost in the mix.</p><p>In many ways, abstraction is just the omission of certain characteristics that make real-world phenomena especially inscrutable to meaningful analysis. Details that are seen as anomalous, divergent, or simply irrelevant to the task at hand are thrown out, while other traits or patterns are elevated in their place. All of this is done to form a coherent model of whichever dynamics the modeler deems most significant. As George Box famously put it, "all models are wrong, but some are useful." Abstraction can produce models that are insightful and beneficial to society just as easily as it can throw up models that are misleading, exploitative, or utterly meaningless. In the case of most cloud software, the abstraction is performed by proprietary algorithms, hidden away on a remote server somewhere that only its owners can ever see or control. The general public simply cannot know what intentions may lie behind their algorithmic abstractions, either good or ill. Ask any content creator who's tried to guess what thumbnail image will get them the most views, or an SEO consultant who's racked their brain for the right combination of keywords to improve their website's search ranking, and they'll tell you just how futile a guessing game that can be.</p><p>Billions of decisions are being made every second on the basis of such cloud-based abstractions, and all for the sake of somebody's model. But <em>whose</em>? Most of those decisions are the sole prerogative of the algorithm's authors, while the overwhelming majority of us are relegated to being the mere <em>objects of their abstractions</em>, even if we never use the particular cloud software in question. Users and non-users alike are seldom granted any knowledge of the decisions being made that impact our lives, let alone any influence over how those abstractions are formed in the first place. When the phenomenon being abstracted away is an entire economic sector or, worse yet, society as a whole, we forfeit a tremendous degree of agency over our social lives and our very material existence. All that power of abstraction is essentially handed over to just a few over-caffeinated engineers and their even fewer corporate managers. Once in their hands they'll do whatever they deem necessary for the sake of scale, often to the detriment of our communities and ultimately to the sole benefit of their company's shareholders.</p><p>That imbalance of control is <em>the definitive metric for scalability</em> and the primary rationale for scaling up so much tech infrastructure in the first place. Another implicit assumption of scalability is that whatever measure is used to indicate a company's total market share or asset valuation – e.g., the number of active users, payments processed, quarterly revenues, etc. – that value is expected to increase at a <em>geometric rate</em> with respect to the total number of employees and capital assets needed to achieve said increase. A mere <em>linear rate</em> of growth would be seen as an abject failure. Whether the market valuation is expressed in users, dollars, or some other unit, in order to be commensurable with the number of employees or other operating costs, they must both be regarded as measures of socioeconomic value, in one form or another.</p><p>Putting assets and liabilities together in a ratio this way also implies that what's being scaled represents a form of equity. It essentially amounts to an unequal exchange of socioeconomic value, and if we assume naturally that a positive equity valuation is the desired outcome, the critical difference in value always flows upward. To put it more bluntly, it's a form of wealth extraction, plain and simple, where the rich only get richer. Furthermore, if the projected growth rate (e.g., equity over time) must rise geometrically in order to be deemed "scalable," then scalability is just an expression for the rate at which a technology system can perpetuate and increase socioeconomic inequality over time. Given the informational and communicative nature of such systems, especially in comparison with pre-digital methods of scaling economic production, it must be emphasized that such inequality will be at once economic as well as social in nature, effecting both how resources are allocated and who controls the allocation process. Scalability, in other words, must also be viewed as essentially <em>a measure of extractiveness and social control</em>.</p><p>Social control and extractivism are nothing new, of course, and computers aren't unique in their ability to scale them; for millennia prior to the invention of integrated circuits, ancient bureaucrats did just fine with their abacuses, law books, <em>quipu</em>, and clay tablets. Where computerized scaling differs is in the <em>rate of extraction</em> and the <em>degree</em> or <em>granularity of control</em> it can achieve relative to the amount of effort it requires to implement and enforce. In this respect, it exceeds all previous means of scaling by orders of magnitude.</p><h2 id="info-trawlers" tabindex="-1">Info Trawlers <a class="header-anchor" href="https://www.runrig.org/posts/against-scale.html#info-trawlers" aria-label="Permalink to &quot;Info Trawlers&quot;">​</a></h2><p>The enormous informational complexity these tools purport to scale is so far in excess of what all the world's engineers, managers, and shareholders can ever hope to apprehend – at least with any semblance of competence or intentionality. Despite the relative ease with which it enables their control over nearly every aspect of our daily lives, scalability is a very sloppy means of control. The people wielding it don't know or care about the full detail being erased in the act of scaling, so long as it doesn't hurt their bottom line. And yet, however ineptly they may wield this power, it remains a very dangerous form of control. As with many forms of industrialization, scalability can prove all the more harmful through the sheer bluntness of the tool, even when no malice is intended. Inevitably, this immense power will be applied to a needlessly wide range of social functions, across diverse cultures and with reckless indifference, because in spite of what damage it may incur, any greater precision would only be seen as an unjustified cost to shareholders and a mere nuisance to engineers.</p><p>Like an <a href="https://www.youtube.com/watch?v=IzG9AwlypaY" target="_blank" rel="noreferrer">ocean trawler</a> that obliterates square miles of seafloor habitat, along with the full diversity of marine life it sustains, all just to harvest a few scallops and discard three quarters of its total catch – so, too, scalability can cut across a wide swath of our social and natural environs, wreaking havoc with our lives and wasting untold resources, all while its operators scarcely pay any notice to the destruction left in their wake.</p><p><img src="https://www.runrig.org/assets/ocean-trawler-attenborough-2025.BcF9LlhV.png" alt="&quot;Still frame from David Attenborough's Ocean (2025), depicting an industrial
bottom trawler decimating the seafloor off the channel coast of southern
England&quot;" title="Still frame from David Attenborough's Ocean (2025), depicting an industrial
bottom trawler decimating the seafloor off the channel coast of southern
England"></p><p>I don't polemicize against scale because I oppose widespread adoption of new and effective digital tools. I just don't think that technology should be designed, owned, and controlled by a tiny number of elites, who then get to impose it upon the masses whether we want it or not. I also take especial exception when it becomes clear that those elites have their heads up their own asses and refuse to see the unparalleled damage they are doing to the rest of us. Finally, I think we're quite past the point of reinterpreting "scale" to mean anything else apart from such wanton devastation. The metaphor is too embroiled with these practices to rehabilitate it now.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/against-scale.html#fn2" id="fnref2">[2]</a></sup></p><h2 id="socializing-our-computational-abstractions" tabindex="-1">Socializing Our Computational Abstractions <a class="header-anchor" href="https://www.runrig.org/posts/against-scale.html#socializing-our-computational-abstractions" aria-label="Permalink to &quot;Socializing Our Computational Abstractions&quot;">​</a></h2><p>All the same, I still contend that new computational abstractions can just as well play a critical role in overturning these injustices. After all, that is my entire purpose with Runrig: to develop the necessary methodologies, relationships, and infrastructure to bring more liberatory technologies into my own community, and then with some luck, to share them more widely.</p><p>It was with that in mind that I first proposed the table at the start of this article, as a rebuttal to the various abstractions imposed by venture capital funding models. Exploitative abstractions like scaling have been so normalized in the tech industry that they are taken for granted even by free software maintainers and advocates, including myself at times.</p><p>Technology does not have to blindly <em>scale the production and reproduction of our socio-economic systems</em>, to the exclusion of all other concerns. It's not obliged to turn our communities into more efficient resource pumps for <em>capital accumulation</em>. We can choose different abstractions and only decide to scale them when we have group consensus. We can co-develop new abstractions for <strong>distributing control</strong> of our production systems more evenly, while also <strong>diffusing the costs</strong> of maintaining them. Instead of <em>consolidating markets</em> into fewer and fewer hands, we can <strong>expand the zone of participation</strong>, along with our capacity for collective action. And although we live for now under capitalism, where technocratic <em>rent-seeking</em> is the order of the day, we can still choose not to reproduce those dynamics with our labor and technology. Instead, let's use them to <strong>organize bulwarks of worker power</strong> that are more resilient to such rent-seeking efforts, as well as other forms of attack.</p><p>Much of this is just a convoluted restatement of mutual aid's basic tenets, and I'm by no means the first to apply them to food and technology. I reframe them this way as a response to specific critiques about free software and cooperative technology. Namely, there's a view that truly robust, maintainable software must be amply funded through capital investments, public grants, or large donations from private foundations – at least, for halfway decent software anyone wants to use. Implicit in this claim is an assumption that good software <em>must</em> be able to scale, or else it's either not very good or it can't help very many people. It's not surprising to hear this charge coming from the startup industry, but beliefs of this sort are almost just as common among advocates for free software and regenerative agriculture.</p><p>I can fully sympathize with these concerns, and I share the pragmatic outlook that I think gives rise to such claims. The high-minded ideals of software freedom and cooperative economics must be balanced against fair compensation for developers and other support staff so that they can deliver the kind of safe, reliable, easy-to-use software that users deserve. It's a tough nut to crack, when you take a realistic account of all the labor, expertise, and long-term commitments needed to accommodate each and every one of those demands. Alternative funding models do exist, but I believe they're poorly attested within free software circles, as well as within conventional industries like agriculture or whichever sector we choose to address.</p><p>I've indicated here a few alternatives to "scaling" but only as a metaphor (e.g., "diffusing costs" or "distributing control"). I've offered nothing comparable to scaling in terms of its power for abstraction, let alone a feasible design for achieving it. For that, we do need to get more specific and talk about architecture, as much as I like to make a fuss about putting <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#ecology-over-architecture"><em>ecology over architecture</em></a>. So next time, I'll cut straight to the chase; I'll layout what I believe will be a central architectural pattern for much of Runrig's future development: <em>federated municipal platforms</em>.</p><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>Academic scalability is a pretty dry body of literature, even as theoretical computer science goes, but to get a sense, see <a href="https://dl.acm.org/doi/10.1145/1465482.1465560" target="_blank" rel="noreferrer">Amdahl's Law</a> and <a href="https://arxiv.org/abs/0808.1431v2" target="_blank" rel="noreferrer">Gunther's Universal Scalability Law</a>. The theoretical physics behind computational limits is actually a lot more approachable and fun to explore,. in my opinion. On her YouTube channel <em>Up and Atom</em>, Jade Tan-Holmes gives a fantastic explanation of <a href="https://www.youtube.com/watch?v=XY-mbr-aAZE" target="_blank" rel="noreferrer">"Why Pure Information Gives Off Heat"</a> according to <a href="https://en.wikipedia.org/wiki/Landauer%27s_principle" target="_blank" rel="noreferrer">Landauer's Principle</a>. To understand how Planck's constant and the Uncertainty Principle combine to fix a hard upper limit on the volume of information that can be transmitted over a fixed period of time, see <a href="https://www.youtube.com/watch?v=0OOmSyaoAt0" target="_blank" rel="noreferrer">"What is the maximum Bandwidth?"</a> with Prof. Mike Merrifield and Brady Haran from <em>Sixty Symbols</em>. It's far more useful, in my opinion, to get a beginner's intuition for the <em>physicality of information</em> than to memorize a bunch of equations for scaling systems that have no business being that big to start with. <a href="https://www.runrig.org/posts/against-scale.html#fnref1" class="footnote-backref">↩︎</a></p></li><li id="fn2" class="footnote-item"><p>I don't know if a non-technical audience would appreciate the full extent to which capitalistic exploitation is entangled with the whole concept of technological scalability, but software developers should be able to spot it instantly.</p><p>Look at any of the most common (or most extreme) approaches to scaling: containerized swarms and clusters, database sharding, MapReduce, data warehouses, data lakes, massively parallel processor arrays, etc. These techniques scale up the number of operations that can be performed or the number of bits that can be stored, but they aren't intended to scale up the complexity of the underlying computing model – some might say that defeats the whole point! And so they do little or nothing to accommodate any greater complexity in the domain model itself, which is where computational control can be handed off to the end user to decide for themselves what programs will positively impact their material lives. For all that massive parallelism and distributed architecture, the potential for human intervention becomes increasingly siloed and extremely centralized. It's analogous to scaling a bitmap image from 32x32 to 64x64 pixels. You can do it easily enough by transforming every single pixel into a homogenous 2x2-pixel block, each one a precise replica of the original, but you haven't added any information or finer detail to the image. You just quadrupled the number of bits you now need to store or transmit it. There's no increase in the significance of what's been scaled, no new knowledge, no refinement.</p><p>This is what technological scaling represents today, in essence. Unless all the familiar techniques are rewritten from scratch or tossed out entirely, this is the definition of scaling that technologists are stuck with for the foreseeable future. We must adopt new metaphors if we want to break out of this established pattern. <a href="https://www.runrig.org/posts/against-scale.html#fnref2" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Farm Flow Backstory]]></title>
        <id>https://www.runrig.org/posts/farm-flow-backstory.html</id>
        <link href="https://www.runrig.org/posts/farm-flow-backstory.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2025-05-26T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Background on the Farm Flow project's origins, how Runrig became involved, and our initial assessments.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Farm Flow Backstory</h1><p><strong>The project's origins &amp; Runrig's initial assessments</strong></p></header><div style="position:relative;" class="vp-doc _posts_farm-flow-backstory" data-v-e6f2a212=""><div><p>In the early spring of 2024, I was approached about consulting for a farmer-led software project called Farm Flow. At first, I viewed the project the way a software generalist and independent contractor would. I consciously guarded myself against becoming the proverbial "hammer that sees every problem as a nail" – that is, I did not want to force Farm Flow into Runrig's model for software design. I said as much to the software's creator, Matthew Fitzgerald of Fitzgerald Organics, on multiple occasions throughout the course of our early evaluation. It was no accident, however, that the project's underlying requirements and ultimate goals brought it into close alignment with my own stated objectives for Runrig. I was introduced to Matthew through Samuel Oslund of the 11th Hour Project, and no doubt Sam discerned the affinity between our two projects far more readily than I had.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/farm-flow-backstory.html#fn1" id="fnref1">[1]</a></sup></p><h2 id="the-original-farm-flow-board" tabindex="-1">The Original Farm Flow Board <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-backstory.html#the-original-farm-flow-board" aria-label="Permalink to &quot;The Original Farm Flow Board&quot;">​</a></h2><p>Farm Flow's first implementation was in physical form, which was a credit to the soundness of its design, by my estimate, since it had already demonstrated its effectiveness before any attempt was made to digitize it. I took it to be a positive indicator for its potential as a software project, too, so long as a compelling case could be made for how that might improve upon the physical design or introduce new affordances.</p><p><img src="https://www.runrig.org/whiteboard_2024-06-09-a.jpg" alt="" title="The original Farm Flow whiteboard"></p><p>The physical implementation was a large whiteboard standing roughly 72" wide x 48" high in Matthew's equipment hangar. It was prepared with a grid of about 80 columns by 20 rows, give or take, meticulously etched out in black permanent marker. The grid represented the farm's entire growing season of planned field actions, with a column for every calendar day and a row for every field or planting location. The dates and location names were written in magic marker along the top and left-hand edges, respectively, so that the grid contents could be erased and reassigned with each new season.</p><p>Multi-colored magnetic discs populated the grid cells at various intervals, demonstrating some rather striking patterns, though their precise meaning was not immediately clear to the untrained eye. The rightmost extent of these discs – i.e., the column corresponding to the current date – was hemmed in by an array of magnetic pins, mimicking pushpin thumb-tacks in size and shape. The pins were similarly colored as the discs but translucent and about half their radius, so they stood out less prominently than the discs. The pins represented actions that were still only planned, while the discs represented those already completed. On closer inspection, some discs were even stacked upon others within a single grid cell; clearly some actions, if not all, could be performed on the same day in the same location, conditions permitting. In the wide open space below the grid was a hand-written legend indicating the name of the specific field action each color represented, alongside a collection of unused discs and pins clustered by color.</p><p>Some of the columns were occupied by a line of numbers, one or two digits faintly inscribed with a blue magic marker in each of the grid cells. These indicated rainfall amounts in decimal inches. They rarely coincided with any placed discs, since the actions they would have represented were prohibited by the rain (sometimes for several days following, too). The rainfall quantities varied in magnitude as they ran up and down the column, though only gradually, since the rows representing geographic locations on the farm were grouped by proximity.</p><p>The key to the whole enterprise was that there was nothing at all arbitrary in the arrangement of these field actions. Their precise timing and sequence were determined by a set of standard operating procedures, or SOPs, which were the product of ongoing development by this small team of farmers. The SOPs lived in written form within folders filed into separate trays that hung from the back of the whiteboard itself. The trays also held carbon-copy ticket books, which would be filled out with specific quantities and target values to inform the execution of a given operation at a particular time and place. Space was left on each ticket for the entry of actual values achieved or observed, so that upon completion the ticket could be stored in the appropriate folder for future reference.</p><p>That's the best synopsis I can give in just two paragraphs and it woefully oversimplifies the system as Matthew conceived it prior to my involvement. For more details, he gave an excellent <a href="https://share.mayfirst.org/s/Bj5FknFttsib2LD" target="_blank" rel="noreferrer">presentation on Farm Flow</a> to the OpenTEAM HCD Working Group in 2024 that covers the data analysis and layout of the board.</p><h2 id="a-previous-attempt" tabindex="-1">A Previous Attempt <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-backstory.html#a-previous-attempt" aria-label="Permalink to &quot;A Previous Attempt&quot;">​</a></h2><p>Prior to our introduction, Matthew had commissioned another software team through Upwork. They produced a fairly generic client-server web application, with an SQL database and multi-user access control, plus an iOS app with basic form views for updating the activities and locations. The web dashboard offered several visualizations of the farm locations and activities, but these didn't correspond at all to the unique visual language of the original whiteboard, nor did it capture or display the most critical datapoints and processes in the SOPs.</p><p>This initial prototype was far from a trivial accomplishment; even as typical as those features are, they still entail plenty of complexity to develop and deploy, which I certainly do appreciate. It's also hard to conceive of a final version of Farm Flow that would <em>not</em> require similar functionality for network connectivity, remote persistence, multi-device access, and permission-based collaboration; outside of those typical requirements, however, the application achieved none of what actually makes Farm Flow unique. In the end, nothing from that effort proved salvageable, since communication with their team was always intermittent at best and the source code was never forthcoming.</p><h2 id="deciding-on-a-development-model" tabindex="-1">Deciding on a Development Model <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-backstory.html#deciding-on-a-development-model" aria-label="Permalink to &quot;Deciding on a Development Model&quot;">​</a></h2><p>As I said above, I didn't presume Runrig's model of development would be the ideal fit for Farm Flow's stated aims, at least not before a careful evaluation. Given Matthew's previous track record with third-party developers, I wanted to take special care to recommend a development model that best suited his goals, even if I turned out not to be the best contractor for the job. At the time, funding was provided by <a href="https://madagriculture.org/" target="_blank" rel="noreferrer">Mad Agriculture</a>, an organization that supports regenerative agriculture and cooperative models of land management and financing. Both they and Matthew wanted to ensure that the project remained farmer-owned and controlled. Matthew also sought to earn some additional revenue from the project, so long as it didn't become a second or third fulltime job; running a farm is already two fulltime jobs, at least, and Matthew decidedly wanted to keep farming. On my end, I made clear that I only do work by contract if it is licensed as free and open source software, preferably the GNU Affero General Public License (AGPL). Other prospective funding partners also expressed interest in the project being free and open source.</p><p>Under most standard development models, retaining ownership and control of the software will incur at least one of the following two expenses:</p><ol><li>Lots of your own time and expertise to design and engineer the software yourself, or</li><li>Lots of money to pay someone else to do it for you.</li></ol><p>More often than not, it's some combination of the two, with the money coming from venture capital and the expertise coming from overworked startup employees who've been promised a share in the future equity. If you want to recoup any of those costs, let alone if you'd like there to be some sizeable equity leftover for anyone once all those liabilities have been paid down, you may be inclined to reach for two additional mechanisms to guarantee a stable revenue stream:</p><ol start="3"><li>A proprietary license on at least some portion of the source code, plus</li><li>A reliable means of securing that source code so it cannot be illicitly copied or reverse engineered.</li></ol><p>The necessary security can be achieved by running the proprietary code behind a server that users cannot access directly, or by compiling the code to a binary format before distributing it, plus some digital rights management (DRM) software mixed in for good measure. There are other ways, but those are the most common. Users can subscribe to the service in the former case, or purchase a license and install the binaries in the latter, but either way, they will never see the source code, let alone be able to modify it.</p><p>At a glance, a subscription model may seem like the most feasible means of yielding revenue from a software project, particularly one that includes some sort of web-based server. A proprietary license is not essential to such a model, because even if users can self-host a server that's licensed as free software, few of them will actually want to. Selling managed hosting or support has been a viable means of driving a profit for open source software since <a href="https://www.redhat.com/en/resources/red-hat-enterprise-linux-subscription-guide" target="_blank" rel="noreferrer">Red Hat</a> and <a href="https://wordpress.com/support/com-vs-org/" target="_blank" rel="noreferrer">WordPress</a> pioneered the strategy over two decades ago. A free license, however, will naturally limit your margins, since someone is pretty sure to offer a competing service if you get too greedy and start charging subscription rates too far in excess of the costs of providing that service.</p><p>A proprietary license eliminates that ceiling, at least in theory. Red Hat and WordPress remain profitable, but only because they're able to work within those margins. Support services are the entirety of their business model and open source is their key selling point. It's harder to imagine a significant revenue stream for open source support if you're not providing that support fulltime. You can hire engineers to do the lion's share of the work for you, but still, the margins are essentially capped. Again, if you overcharge for subscriptions or under-compensate your workers to maintain the service, you could end up with your workers or customers being poached, if not outright revolt on all fronts. Either way, your fulltime job will most assuredly become that of a product manager, just to have a fighting chance of keeping the margins viable and the pitchforks at bay.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/farm-flow-backstory.html#fn2" id="fnref2">[2]</a></sup></p><p>All the same, I made the case that <em>even with a proprietary license</em>, an outsized contribution of Matthew's own time and money would be necessary to preserve the level of ownership and control he wanted. So although it would probably never be the source of passive income he hoped for, I recommended that a <em>fully</em> free – i.e., <a href="https://www.gnu.org/licenses/copyleft.en.html" target="_blank" rel="noreferrer">"copyleft"</a> – license like the AGPL was still his best bet for getting the most value from the software while still retaining control of its development.</p><h2 id="the-case-for-free-software" tabindex="-1">The Case for Free Software <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-backstory.html#the-case-for-free-software" aria-label="Permalink to &quot;The Case for Free Software&quot;">​</a></h2><p>In any software project, the more components you have to build from scratch the more time and money you'll need to invest just to reach parity with competing applications in terms of basic functionality and feature richness. Right off the bat, this will divert resources away from implementing the unique features that represent you core value proposition. Furthermore, that doesn't begin to account for the long-term cost of maintenance, which will be even higher for proprietary portions of the code, since you'll have to cover that cost entirely on your own. Throw in marketing and other overhead costs and you can see where that can quickly outstrip the budget for a small, community-driven software project.</p><p>As a proprietary project, you're a small fish in a big pond left to fend for yourself. You're up against the vast resources of Silicon Valley and it becomes an uphill battle just to break even. If you create a distinct product lucrative enough to compete, venture capital will eventually get wise to what you're selling and want a piece. That'll happen as soon as you start earning any kind of profit worthy of notice, especially if that entails taking away a share of their users. Unless you're ready to go toe-to-toe, pound-for-pound with Big Tech, you run the risk of being out-gunned, undercut, and bought out, all in quick succession. At that point, you've wound up exactly in the same predicament you originally intended to avoid: someone else owns your IP (or the knock-off version that just put you out of business), and now you're just another paying subscriber – take it or leave it. Maybe you accept VC investment yourself, giving you enough of an edge to survive or cash out while you're still ahead; however, that more or less amounts to the same loss of control, unless you're incredibly shrewd, and even then, it means you probably haven't sat on a tractor in a <em>very</em> long time.</p><p>As a free software project – or more to the point, as a <em>part of a free software community</em> – you can potentially start way out in front of where you'd be if you had gone the proprietary route. At the risk of sugarcoating it a bit, it's like everyone is first to market, because everyone gets to use each other's stuff and improve on each other's efforts. There's still a ton of hard work required and plenty of caveats to doing it right, but if you're willing to really lean into the cooperative process and engage with the larger community, the rewards can be manifold.</p><p>From a purely economical perspective, you've drastically reduced the amount of time and money you need for up front feature parity, as well as long-term maintenance. Of course, a lot of boilerplate code is open source and not copyleft, so those tools and components would be available to proprietary projects, too, not just other free and open source projects. But this is where leaning into a <em>fully free</em> software development model, with a copyleft license like the GPL or AGPL, can really start to pay off. To start off, you gain access to additional free software as an eligible licensee for those components that are also copyleft. The most critical part, however, comes from thinking <em>not only</em> in terms of simple economic benefits – though don't get me wrong, I'm not ruling those out either! – but rather in terms of the community's total social, political, and ecological benefits, which are no less tangible and can have far greater impact.</p><p>The GNU Affero General Public License is a free software license that ensures everyone can use the software however they see fit, so long as any derivative works they create can also be used freely by everyone else. This is intended to create a virtuous cycle that perpetually enriches the software commons. It is a commitment that all contributors make to one another: namely, that they will seek to build on each other's work and cooperate for the mutual benefit of all, rather than competing against each other, keeping their work siloed, and reduplicating each other's efforts in the process.</p><p>The AGPL also ensures every contributor that they will never be prohibited from later accessing their own contributions. As outlined above, this is an easy trap to fall into with proprietary software, even as its current owner, but this often goes overlooked. Luckily, as the developer of software licensed under the AGPL, the code that you author and deploy for one client is code you can offer to deploy, improve, and extend for your next client. As the sponsor of software licensed under the AGPL, you're free to hire someone else to audit, modify, or improve the software at any time, whether or not you or they were involved in its original development. Users who share their expertise on forums to help other users, or who volunteer their time to documenting and submitting bug reports and feature proposals, will never lose access to the software they worked to make better. By choosing to work together, contributing openly and freely to the same platform, they can all exercise greater control over the project’s direction. Collaboration and openness only amplifies each others efforts, it never diminishes it.</p><h2 id="initial-recommendations" tabindex="-1">Initial Recommendations <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-backstory.html#initial-recommendations" aria-label="Permalink to &quot;Initial Recommendations&quot;">​</a></h2><p>After thorough discussion with Matthew on all of the preceding points, I summarized my initial recommendations for developing the Farm Flow application as follows:</p><ol><li>Prioritize the Farm Flow Board and the quickest pathway to developing an implementation that can be demonstrated with high fidelity, even without a supporting backend or network connectivity.</li><li>Look for ready-to-use, third-party applications that can be adopted early on then later integrated with the Farm Flow Board, such as <a href="https://www.litefarm.org/" target="_blank" rel="noreferrer">LiteFarm</a> or <a href="https://farmos.org/" target="_blank" rel="noreferrer">farmOS</a>. Keep development focused on Farm Flow’s core value proposition of the board and its other unique features.</li><li>Assess interest from potential users and funders before deciding on a backend architecture to support the Farm Flow Board as it develops into a more robust dashboard and nerve center for the other core features.</li><li>Distribute the costs of ownership and control over development; rather than scaling a product, think in terms of organizing support and strategic reach.</li></ol><p>See the <a href="https://www.runrig.org/posts/farm-flow-pilot.html">Farm Flow Pilot</a> and final <a href="https://www.runrig.org/posts/farm-flow-strategy.html">Farm Flow Development Strategy</a> for more information on how the project proceeded.</p><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>The first time I ever tried to fully explain Runrig to anyone else was on a short hike with Samuel on the last day of GOAT 2022. The last in a series of momentous conversations, it came at the precise moment when Runrig started taking definite shape in my own mind, and I attribute much of Runrig's essential characteristics to Sam's astute guidance and constructive feedback. <a href="https://www.runrig.org/posts/farm-flow-backstory.html#fnref1" class="footnote-backref">↩︎</a></p></li><li id="fn2" class="footnote-item"><p>Not to put too fine a point on it, but I summed this up by telling Matthew that it would be hard to create a source of passive income out of Farm Flow without one of us exploiting the other. There's a long history of rentier relations in both agriculture and technology. In agriculture it is called feudalism. More recently, Yanis Varoufakis has made a compelling case that we are entering a new era of what he calls <a href="https://www.yanisvaroufakis.eu/2024/02/04/technofeudalism-a-video-essay-summarising-the-book/" target="_blank" rel="noreferrer"><em>Technofeudalism</em></a>. <a href="https://www.runrig.org/posts/farm-flow-backstory.html#fnref2" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[The Farm Flow Pilot]]></title>
        <id>https://www.runrig.org/posts/farm-flow-pilot.html</id>
        <link href="https://www.runrig.org/posts/farm-flow-pilot.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2025-05-26T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[The history of Farm Flow's development as a Runrig pilot application, with all that entails, including a portable data model.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>The Farm Flow Pilot</h1><p><strong>A maintainable development framework &amp; portable data model</strong></p></header><div style="position:relative;" class="vp-doc _posts_farm-flow-pilot" data-v-e6f2a212=""><div><p>Runrig's role in the development of Farm Flow was not only to produce a pilot app for the board's digital incarnation, but to guide the establishment of a maintainable software project for the long haul. Ideally it would bring immediate value to Fitzgerald Organics and its operations from Day 1, but without requiring Matthew to take on the additional fulltime job as project manager.</p><p>I called this a "pilot" because unlike a "prototype" it was not strictly intended as a throw-away experiment to fill the gap until the <em>real</em> application was built. At the same time, I eschewed the term MVP (minimal viable product) because it wasn't meant to be the definitive product that supplanted the original physical whiteboard that still lived in Matthew's equipment shed, let alone the <em>notional board</em>, which lived in his mind even prior to the whiteboard's construction and which, I'd wager, lives on there still to this day. The difference is that as a <em>pilot app</em>, it was meant to advance the Farm Flow project through <em>real-world usage</em> – not as an idle experiment, but in the everyday, practical work of the farm. Even while the code I wrote no longer runs in the version of the application Matthew uses today, the data it generated does persist. What's more, the code has been documented and is still publicly available as free software licensed under the AGPLv3, so it will no doubt serve to advance similar, future projects.</p><p>This was an important component of the agreement Matthew and I reached when we agreed to work together, and why we chose the copyleft AGPL rather than a more permissive license such as MIT or Apache. I never want Matthew to face the kind of vendor lock-in (or lock-out), which is business-as-usual for most proprietary software companies. Even as its current owner, there's nothing to preclude intellectual property from someday ending up in the hands of a third party, who could very well block Matthew's right to use or modify Farm Flow as he wished. Such things have indeed happened before. I didn't want him to be beholden to me, either, as the only one who understood and could effectively improve and adapt the codebase, should he ever choose to take a new direction. On the other hand, I did not want to lock myself out of access to the technical components I produced for Farm Flow, so I could continue to adapt them to new scenarios and use cases. By using a "share-alike" license, which grants anyone the right to use and modify the software as they like, but with the restriction that any derivative works be licensed similarly, we both enjoy its protections.</p><h2 id="planned-development-cycle" tabindex="-1">Planned Development Cycle <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#planned-development-cycle" aria-label="Permalink to &quot;Planned Development Cycle&quot;">​</a></h2><p>The initial plan to develop the pilot was comprised of three phases, though only the first was completed:</p><ol><li>Low Fidelity Board</li><li>Connectivity &amp; LiteFarm Integration (not completed)</li><li>High Fidelity Board (not completed)</li></ol><p>After completing Phase 1, as described below, it became clear that as a one-person team I was not going to have the total capacity to get the final version across the finish line in time for the 2024 planting season.</p><p>Matthew and I mapped out several scenarios that could have potentially shortened the development cycle. They each came with certain drawbacks, and the possibility that certain features might not be completed or within the ideal timeframe. I tried to show how these would still leave all completed development in relatively stable state where it development could always be resumed again without much difficulty. I illustrated these as "on-ramps" and "off-ramps":</p><p><a href="https://www.runrig.org/farm-flow-on-ramps-and-off-ramps.png" target="_blank" title="Click to Zoom"><img src="https://www.runrig.org/farm-flow-on-ramps-and-off-ramps.png" alt="Flowchart illustrating the 'On-Ramps &amp; Off-Ramps towards a stable &amp; sustainable Farm Flow Pilot Deployment'"></a></p><h3 id="phase-1-low-fidelity-pilot" tabindex="-1">Phase 1: Low Fidelity Pilot <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#phase-1-low-fidelity-pilot" aria-label="Permalink to &quot;Phase 1: Low Fidelity Pilot&quot;">​</a></h3><p>The first phase, as a "lo-fi" implementation, would aim to meet the minimal requirements for representing Farm Flow’s core data points. It would support all essential CRUD operations in terms of both user interactivity and data persistence between sessions, but it would not have a very polished look and feel, nor the fine-tuned ergonomics of a finished application (e.g., drag-n-drop interactions, tool-tips, animated transitions, etc). The goal was to take the shortest path to replicating the essential features of the physical whiteboard in order to get feedback from Matthew and move on to Phase 2, which would add all essential mobile functionality. Final design decisions would be deferred until Phase 3, when real-world dat and practical user feedback would be able to influence the process.</p><p>A demo of the browser-based app is available at <a href="https://farm-flow-board.pages.dev/" target="_blank" rel="noreferrer">farm-flow-board.pages.dev</a>. You will need to import a data file to get started, which can be downloaded as JSON from the project's GitHub repository: <a href="https://github.com/runrig-coop/farm-flow-board/blob/main/public/crop-2023.json" target="_blank" rel="noreferrer"><code>crop-2023.json</code></a>. This demo should considered experimental and highly unstable; it will not be provided with ongoing support.</p><h3 id="phase-2-connectivity-litefarm-integration" tabindex="-1">Phase 2: Connectivity &amp; LiteFarm Integration <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#phase-2-connectivity-litefarm-integration" aria-label="Permalink to &quot;Phase 2: Connectivity &amp; LiteFarm Integration&quot;">​</a></h3><p>The reason I didn't want to put too much effort into the ergonomics of the lo-fi pilot was because the primary method of entry was intended to be LiteFarm's mobile application. Part of the benefit of that was it would enable Matthew to begin using LiteFarm for data entry before Phase 1 was even finished. Getting a first approximation of the board that could connect to "live" data as it came in from the field was not only essential to Matthews daily operations, but to the design process itself. Matthew's feedback on that complete workflow would be a prerequisite for all the most significant design choices.</p><p>The first order of business would be to integrate the board’s interface, data model, and storage with LiteFarm’s servers. Users needed to authenticate securely with LiteFarm and synchronize their data upon all CRUD operations, and at the start and end of each session. Once this is achieved, LiteFarm can be effectively used to capture practical data from mobile devices in the field, while also providing a supplemental dashboard for reviewing data from desktop or mobile screens.</p><h3 id="phase-3-high-fidelity-board" tabindex="-1">Phase 3: High Fidelity Board <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#phase-3-high-fidelity-board" aria-label="Permalink to &quot;Phase 3: High Fidelity Board&quot;">​</a></h3><p>Once the entire workflow was implemented, we would have made final design decisions and brought significant enhancements to the board's visual display and general usability. Design details such as animated transitions and responsiveness to different screen sizes would have been fine-tuned, with attention given to the overall user experience (UX). This would have been the point at which to settle on a consistent theme and design elements, such as color palette, typography, and spacing. This would have hopefully indicated a path towards a distinct brand for Farm Flow in its continued development.</p><h2 id="architecture-design" tabindex="-1">Architecture &amp; Design <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#architecture-design" aria-label="Permalink to &quot;Architecture &amp; Design&quot;">​</a></h2><p>The following details are adapted from the project repository's <a href="https://github.com/runrig-coop/farm-flow-board" target="_blank" rel="noreferrer">README</a> file, intended for a more technical audience.</p><h3 id="runrig-design-principles" tabindex="-1">Runrig Design Principles <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#runrig-design-principles" aria-label="Permalink to &quot;Runrig Design Principles&quot;">​</a></h3><p>The Farm Flow board has been developed in accordance to several of Runrig's design principles, most notably:</p><ul><li>Identify the <strong>core competency</strong> of the application that will most immediately add value to the user's existing workflow, without reproducing functionality that already exists in other applications.</li><li>Adapt the application to function as a <strong>middleware</strong> or "glue service" that can augment existing FOSS applications and services, while still remaining relatively independent and agnostic of the host application's service architecture.</li><li>Maintain <strong>data independence</strong> and separate the domain model from the service architecture as much as possible. Ensure that <strong>data portability</strong> is a first-order feature from the very first iteration.</li></ul><h3 id="typescript-vue-js-and-html-canvas" tabindex="-1">TypeScript, Vue.js, and HTML Canvas <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#typescript-vue-js-and-html-canvas" aria-label="Permalink to &quot;TypeScript, Vue.js, and HTML Canvas&quot;">​</a></h3><p>The application uses TypeScript for its versatility in browser, server, and desktop environments. This first pilot is implemented as a single-page application (SPA) that can be deployed to any CDN service, such as those provided by Vercel, Netlify or Cloudflare. Browser-based persistence is provided by <a href="https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API" target="_blank" rel="noreferrer">IndexedDB</a> and fully offline-first functionality could be introduced easily by dropping in <a href="https://vite-pwa-org.netlify.app/" target="_blank" rel="noreferrer">a "zero-config" plugin</a>.</p><p><a href="https://vuejs.org/" target="_blank" rel="noreferrer">Vue</a> was chosen as the frontend framework along with <a href="https://vite.dev/" target="_blank" rel="noreferrer">Vite</a> for tooling, partly out of preference and familiarity, but also because they provide first-class support for both consuming and generating <a href="https://vuejs.org/guide/extras/web-components.html" target="_blank" rel="noreferrer">web components</a>. This affords an easy escape hatch to port Farm Flow to other applications as a component library without the need to manually port the Vue components and reactive state to other frameworks, such as React or Svelte.</p><p>The core rendering logic for the board itself has been implemented with the browser's native <a href="https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API" target="_blank" rel="noreferrer">Canvas API</a>, without the use of Vue components or reactive state whenever possible. This is again to make it easier to port this core rendering logic to other JavaScript frameworks, such as React or Svelte. Because the Canvas API is part of the greater <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API" target="_blank" rel="noreferrer">WebGL API</a>, which itself conforms closely to <a href="https://www.khronos.org/opengl/" target="_blank" rel="noreferrer">OpenGL</a>, there is also the possibility of porting this logic to other languages that support native desktop SDKs and other environments.</p><h3 id="farmos-data-model" tabindex="-1">farmOS Data Model <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#farmos-data-model" aria-label="Permalink to &quot;farmOS Data Model&quot;">​</a></h3><p>In the interest of promoting data portability and interoperability with other existing services, Farm Flow has loosely adopted the <a href="https://farmos.org/model/" target="_blank" rel="noreferrer">farmOS Data Model</a> to structure its internal state and on-devise database (IndexedDB). Adoption of the farmOS Data Model has been taking hold in more and more projects beyond the farmOS ecosystem itself, particularly with its adoption by members of the <a href="https://openteam.community" target="_blank" rel="noreferrer">OpenTEAM community</a>.</p><p>The farmOS Data Model extends Drupal's Entity-Relationship Model, which includes a two-tiered inheritance model of <em>entities</em> and <em>bundles</em>. Entities are the higher, functional tier of classification, including <em>assets</em>, <em>logs</em>, <em>users</em>, etc. Bundles are lower, categorical tier, with <em>land</em>, <em>products</em>, <em>animals</em>, <em>equipment</em> being examples in the <em>asset</em> family of entities. Accordingly, they "bundle" together relevant fields such as the <em>manufacturer</em> and <em>serial number</em> in the case of equipment, or <em>birthdate</em> and <em>sex</em> in the case of animals. All resources must be classified by both <em>entity</em> and <em>bundle</em>. The combination of <em>entity</em> and <em>bundled</em> is considered that resource's <em>type</em>, and is represented as a JSON string by the entity name (singular) followed by two dashes (<code>"--"</code>) then the bundle name – for example, <code>"asset--equipment"</code>, <code>"log--harvest"</code>, or <code>"taxonomy_term--season"</code>.</p><p>For the time being, Farm Flow only employs a small subset of the entities and bundles that come with a standard farmOS installation, which are listed below. Non-standard entities, which have not been implemented as farmOS modules but otherwise conform to specifications, are denoted with asterisks (*).</p><ul><li>Assets <ul><li>Land (aka, location)</li><li>Plant (a specific planting or succession)</li></ul></li><li>Logs <ul><li>Activity</li><li>Harvest</li><li>Input</li><li>Seeding</li></ul></li><li>Plans <ul><li>Farm Flow Board*</li></ul></li><li>Taxonomy Terms <ul><li>Plant (crop or varietal)</li><li>Standard Operation Procedures*</li></ul></li></ul><p>All of these resources must have at least two fields: an <code>id</code> string represented by a UUID (v4), and a <code>type</code>, which is a JSON string structured in the <code>"{type}--{bundle}"</code> format. On their own, the <code>id</code> and <code>type</code> fields form a compete <em>identifier</em> that can be used to indicate a relationship to another resource.</p><p>We're ignoring many of the other fields included in each of these bundles by default, since they're not needed in this application and can be derived from defaults at a later time, if at some point full integration with a farmOS-compliant system becomes desirable. Their approximate type definitions are provide below in abbreviated form. For the most up-to-date and complete definitions, see <a href="./src/data/resources.ts"><code>/src/data/resources.ts</code></a>.</p><h4 id="assets-land-location-and-plant" tabindex="-1">Assets: land (location) and plant <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#assets-land-location-and-plant" aria-label="Permalink to &quot;Assets: land (location) and plant&quot;">​</a></h4><div class="language-ts vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ts</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">interface</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> LocationResource</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  id</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> UUID</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  type</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> 'asset--land'</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  name</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> string</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span>
<span class="line"></span>
<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">interface</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> PlantResource</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  id</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> UUID</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  type</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> 'asset--plant'</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  crop</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> CropIdentifier</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> null</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  location</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> LocationIdentifier</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> null</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><h4 id="logs-activity-harvest-input-and-seeding" tabindex="-1">Logs: activity, harvest, input, and seeding <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#logs-activity-harvest-input-and-seeding" aria-label="Permalink to &quot;Logs: activity, harvest, input, and seeding&quot;">​</a></h4><div class="language-ts vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ts</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">interface</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> LogResource</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  id</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> UUID</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  type</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span></span>
<span class="line"><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">    'log--activity'</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span></span>
<span class="line"><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">    'log--harvest'</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span></span>
<span class="line"><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">    'log--input'</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span></span>
<span class="line"><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">    'log--seeding'</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  name</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> string</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  date</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> Date</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  location</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> LocationIdentifier</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> null</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  operation</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> OperationIdentifier</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> null</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  plant</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> PlantIdentifier</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> |</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> null</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  notes</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> string</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><h4 id="plans-farm-flow-board" tabindex="-1">Plans: Farm Flow Board <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#plans-farm-flow-board" aria-label="Permalink to &quot;Plans: Farm Flow Board&quot;">​</a></h4><div class="language-ts vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ts</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">interface</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> BoardInfo</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  id</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> UUID</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  type</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> 'plan--farm_flow_board'</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  name</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> string</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  dateRange</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> [</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">Date</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">, </span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">Date</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">],</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  crops</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> PlantIdentifier</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">[],</span></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><h4 id="taxonomy-terms-plant-crop-and-operation-sop" tabindex="-1">Taxonomy Terms: plant (crop) and operation (SOP) <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#taxonomy-terms-plant-crop-and-operation-sop" aria-label="Permalink to &quot;Taxonomy Terms: plant (crop) and operation (SOP)&quot;">​</a></h4><div class="language-ts vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ts</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">interface</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> CropTerm</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  id</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> UUID</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  type</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> 'taxonomy_term--plant'</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  name</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> string</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span>
<span class="line"></span>
<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">interface</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> OperationTerm</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  id</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> UUID</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  type</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> 'taxonomy_term--standard_operating_procedure'</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">  name</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> string</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">;</span></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><h2 id="final-development-strategy" tabindex="-1">Final Development Strategy <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-pilot.html#final-development-strategy" aria-label="Permalink to &quot;Final Development Strategy&quot;">​</a></h2><p>See the final <a href="https://www.runrig.org/posts/farm-flow-strategy.html">Farm Flow Development Strategy</a> for more information on how the project proceeded.</p></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Farm Flow Development Strategy]]></title>
        <id>https://www.runrig.org/posts/farm-flow-strategy.html</id>
        <link href="https://www.runrig.org/posts/farm-flow-strategy.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2025-02-26T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[The purpose of this document is to provide a high-level strategy for the development of the Farm Flow application, together with practical recommendations for how these strategies might be implemented, in order to achieve the desired outcomes of Farm Flow's various stakeholders. Runrig consulted with Fitzgerald Organics, Cloudburst Studio, and the 11th Hour Project to gather feedback and insights to their objectives. Aspects of business development, technical feasibility, ecosystem impact, user experience, and the overall design requirements have all been taken into consideration.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Farm Flow Development Strategy</h1><p><strong>A strategy for Farm Flow's development with practical recommendations for how to implement it</strong></p></header><div style="position:relative;" class="vp-doc _posts_farm-flow-strategy" data-v-e6f2a212=""><div><p>The purpose of this document is to provide a high-level strategy for the development of the Farm Flow software platform. It will include practical recommendations for how that strategy may be implemented and how it will achieve the desired outcomes of Farm Flow's various stakeholders. Runrig consulted with Fitzgerald Organics, Cloudburst Studio, and the 11th Hour Project to gather feedback and insights to their objectives. Aspects of business development, technical feasibility, ecosystem impact, user experience, and the specific design requirements have all been taken into consideration.</p><p>It is precisely this varied collection of interests and goals that must somehow be synthesized into a single, coherent strategy with actionable recommendations. With that in mind, I'd like to offer this provisional summary of Farm Flow's main motivations and the purpose of the software project as a whole.</p><div class="info custom-block"><p class="custom-block-title">Summary of Farm Flow's Main Motivations &amp; Purpose</p><p>As a software platform, social enterprise, and knowledge ecosystem, Farm Flow provides a comprehensive solution for crop planning, team management, and operational analysis, serving farms of all shapes and sizes. A key value proposition is the Farm Flow Board, a visualization of all the field tasks to be carried out for every crop on the farm, as well as Standard Operating Procedures (SOPs) that prescribe how each task is to be performed. With these utilities in hand, team members can coordinate their activities to achieve targeted production volumes, desired costs savings, and positive environmental impacts. As a wider community and a forum for exchanging knowledge, Farm Flow also connects farmers to agronomists, technicians, designers, and other stakeholders, activating new channels for collaboration and innovation.</p></div><p>No doubt this glosses over many of the finer points and perspectives, so I invite any suggestions on how to improve this statement as development proceeds.</p><h3 id="strategies-recommendations" tabindex="-1">Strategies &amp; Recommendations <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#strategies-recommendations" aria-label="Permalink to &quot;Strategies &amp; Recommendations&quot;">​</a></h3><p>The strategy I recommend can be broken down into the three constituent strategies that follow, with a dedicated section below presenting the full rationale and practical recommendations for each:</p><ol><li><a href="https://www.runrig.org/posts/farm-flow-strategy.html#focus-on-core-competencies">Focus on Core Competencies</a>, namely <a href="https://www.runrig.org/posts/farm-flow-strategy.html#the-farm-flow-board">The Farm Flow Board</a> and <a href="https://www.runrig.org/posts/farm-flow-strategy.html#sops-as-user-defined-algorithms">SOPs</a></li><li><a href="https://www.runrig.org/posts/farm-flow-strategy.html#actively-promote-data-portability">Actively Promote Data Portability</a></li><li><a href="https://www.runrig.org/posts/farm-flow-strategy.html#embrace-software-freedom-as-a-business-model">Embrace Software Freedom as a Business Model</a></li></ol><h2 id="focus-on-core-competencies" tabindex="-1">Focus on Core Competencies <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#focus-on-core-competencies" aria-label="Permalink to &quot;Focus on Core Competencies&quot;">​</a></h2><p>Ten years ago, the range of mature software available to farmers for managing their operations and production was quite limited, with few options for even the most general applications, like crop planning, team management, and task scheduling. Today, that is no longer the case. There now exist redundant offerings for most generic use cases, even when considered across market segments based upon price, farm type or scale, and platform support. Among open source and free software alternatives, too, there exist several mature options, such as LiteFarm, farmOS, and Brinjel, all of which provide robust solutions for relatively low cost or for free.</p><p>In light of this, a stated aim of Runrig's preliminary discovery work was to:</p><blockquote><p>Identify the <strong>core competency</strong> of the application that will most immediately add value to the user's existing workflow, without reproducing functionality that already exists in other applications.</p></blockquote><p>The two strongest core competencies of Farm Flow that Runrig has been able to identify are <a href="https://www.runrig.org/posts/farm-flow-strategy.html#the-farm-flow-board">the Farm Flow Board</a>, as a unique visualization and user experience, and <a href="https://www.runrig.org/posts/farm-flow-strategy.html#sops-as-user-defined-algorithms">SOPs</a>, as user-defined algorithms that belong to those users.</p><h3 id="the-farm-flow-board" tabindex="-1">The Farm Flow Board <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#the-farm-flow-board" aria-label="Permalink to &quot;The Farm Flow Board&quot;">​</a></h3><p><img src="https://www.runrig.org/whiteboard_2024-06-09-a.jpg" alt="" title="The original Farm Flow whiteboard"></p><p>The first core competency is of course the Farm Flow Board itself. It presents a unique and comprehensive view of the farm's crop plan with the many field actions it requires over the course of the season. To highlight the structural qualities that offer the most distinct value to the user:</p><ul><li><strong>Event-based vs Duration-based Elements</strong>: Unlike most Gantt charts, the primary visual elements populating the board are the pinpoint activities that punctuate a moment in time, not the durations intervening between the start and end of an activity.</li><li><strong>The Horizontal Axis</strong>: Each row is an integral unit of the board, representing the planting of a particular crop at a given location. An important aspect of each row is the sequential nature of the several activities that can occupy the cells. A complex set of dependencies governs when each activity can be scheduled, based on such factors like the amount of time since the previous activity, recent weather events, and overall progress and maturation of the crop.</li><li><strong>The Vertical Axis</strong>: At any moment during the season, there will be a cluster of columns representing recent and upcoming calendar dates that focuses the user's attention. The field activities within this cluster present a sort of "wavefront" of significant data points: it is the critical decision window at any moment during the planting season. Because the rows are grouped by the geographic proximity of crop location, shifting one's attention up and down a column corresponds loosely to the distance between crops. There is an aspect of directionality along the vertical axis, too, since moving vertically towards or away from a given row on the board corresponds to real movement to and from locations on the farm. This is most conspicuous when observing the rainfall amounts for one day (a single column) and how they rise and fall in a relatively smooth gradient up and down the column. When this vertical directionality is combined with the direction of time inferred by the horizontal axis, it offers a unique opportunity for representing these gradients across the 2-dimensional plane of the board, as expounded below.</li></ul><h4 id="heat-map-vs-gantt-chart" tabindex="-1">Heat Map vs Gantt Chart <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#heat-map-vs-gantt-chart" aria-label="Permalink to &quot;Heat Map vs Gantt Chart&quot;">​</a></h4><p>One way to analyze the visual and geometric relationships of the Farm Flow Board is to view them as a <strong>2-dimensional vector space</strong> or <strong>gradient field</strong>; the distance between any one row or column and another correlates to some measurable distance between two different times and locations on the actual farm, as well as the direction to and from each other. Along the horizontal axis, this is the length and direction of time, in a linear 1:1 relationship with actual calendar days. A less strict, but approximate relationship exists along the vertical axis, too, correlating to distance between locations on the farm. The <strong>magnitude and directionality of values along <em>both axes</em></strong> is one subtle way the Farm Flow Board differs from most Gantt charts and crop planning visualizations, where often such a correlation only exists along the horizontal.</p><p>What makes the Farm Flow Board most distinct as a visualization, however, is that the key time elements on the chart are <strong>not <em>extended durations</em> of time but rather <em>pinpoint events</em> separated by intervals</strong> – that is, not the typical "bars" used by Gantt charts and most crop plans, but markers that represent discrete instances of activity. This allows for the interval between events to be represented as a gradient rather than as a solid block, and such a gradient can be applied two-dimensionally in both time and space. Further possibilities emerge if other properties like growing degree-days (GDD) and the rate of change between events or locations are also interpreted as vector gradients. In turn, these vectors can be represented visually as shaded gradients, rendering the Farm Flow Board more like a <a href="https://www.atlassian.com/data/charts/heatmap-complete-guide" target="_blank" rel="noreferrer">gridded heat map</a> than a Gantt chart.</p><p><img src="https://www.runrig.org/heatmap-categorical.png" alt="" title="Source: Atlassian"></p><p>The potential of this approach has not been fully explored but there is tremendous opportunity in what could be achieved by applying <strong>color gradients</strong> to depict the rate of change between cells – e.g., elapsed time, accumulated rainfall, or changes in soil moisture. Possibilities are not limited to color or the space between activities, but can make use of the <a href="https://observablehq.com/@d3/hexbin-area" target="_blank" rel="noreferrer">size and shape of the markers</a> or <a href="https://observablehq.com/@observablehq/plot-wealth-health-nations" target="_blank" rel="noreferrer">animations bound to a slider widget</a> controlled by the user.</p><p><img src="https://www.runrig.org/plot-hexbin-binwidth.png" alt="" title="Source: Observable"></p><p>Each visual cue adds a new dimension for comparing the data. How might such gradients prove even more effective in a dynamic display, where the gradient colors can intensify and shift hue as the activity marker itself is moved back and forth across the grid in real time? To my knowledge, nothing like this exists in any existing crop planning applications. It may also be worth exploring other ways that gradient values could be represented on a <a href="https://observablehq.com/@d3/hexbin-map" target="_blank" rel="noreferrer">spatial heat map</a> or <a href="https://observablehq.com/@d3/bivariate-choropleth" target="_blank" rel="noreferrer">choropleth</a> that allow for greater accuracy and emphasis to be placed on the geographic relationships rather than temporal ones.</p><p><img src="https://www.runrig.org/hexbin-map.png" alt="" title="Source: Mike Bostock for D3.js and Observable"></p><p>It should also be stressed that this doesn't preclude typical Gantt-style representations, only that a significant source of value could be lost if Gantt-style blocks are prioritized over heat-map-style gradients, at least until proven otherwise. Gantt charts are already offered by several crop planning apps already on the market today, but the heat-map approach has yet to be exploited.</p><p>The value a user assigns to these features may depend on the type and number of crops they have in production, their farming practices, and the overall scale of their farm, particularly where these may differ from to Fitzgerald Organics. A smaller farm growing a larger number of specialty crops might value geographic groupings less highly, or may not adhere to such strict sequences between activities. It is possible, we have to admit, that by focusing on this single value proposition, Farm Flow may limit the diversity of farm types that find it uniquely appealing or helpful; however, that could also be the key factor allowing Farm Flow to thrive within a distinct, untapped niche, rather than struggling to compete within crowded field. It's also quite possible that the core visual and algorithmic characteristics – specifically, <strong>rendering gradient values across a 2D plane that correlates to calendar days and geographic space</strong> – could be generalized to render other datasets, plus the user scenarios they represent, so long as they can be mapped to a 2D vector space and scalar gradients. By perfecting its unique features over the long term and adapting its <em>specialized views</em> to more <em>generalized datasets</em>, Farm Flow may never want for a broader range of appeal. This niche-based approach, when combined with an emphasis on <a href="https://www.runrig.org/posts/farm-flow-strategy.html#actively-promote-data-portability">data portability</a> and <a href="https://www.runrig.org/posts/farm-flow-strategy.html#embrace-software-freedom-as-a-business-model">openness</a>, could offer the best of both worlds, where farmers of all sorts can enjoy the specialized features of Farm Flow and defer to other applications for more a more generalized user experience.</p><p>The SOPs may in fact provide the ideal delta values for sorting the rows and determining gradient visualizations. As explained in the next section, the key to these SOPs is specifically the way they represent user-defined criteria for evaluating the board's primary data points – that is, the activities themselves – which are basically <em>instances of different classes of SOP</em>.</p><h3 id="sops-as-user-defined-algorithms" tabindex="-1">SOPs as User-defined Algorithms <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#sops-as-user-defined-algorithms" aria-label="Permalink to &quot;SOPs as User-defined Algorithms&quot;">​</a></h3><p>Standard Operating Procedures, or <strong>SOPs</strong>, are the second core competency identified in Runrig's initial assessment. The SOP, as the general <em>form of an activity</em>, should be distinguished from the activity itself, which is merely <em>one instance of the SOP</em> that has been scheduled or completed. Each SOP is in essence a <strong>user-defined algorithm for how to perform a vital task</strong>, meant to achieve a corresponding and observable outcome, impacting the overall success of the crop.</p><p>Just as important as the individual SOPs are <strong>planned sequences</strong> of SOPs (or perhaps "SOP Flows"?) that the user determines should be carried out in order to achieve a desired outcome for the crop as well as the soil and other environmental factors. Like the individual SOPs, these sequences should be defined by the user, rather than hard-coded into the system by developers.</p><p>Taken all together, SOPs and SOP Sequences, along with their constituent target values, are effectively <strong>algorithms as user data</strong>, and the user should be granted the same right to control, modify, share, or keep them private just as they would any other form of user data.</p><h4 id="target-values-outcomes-metrics" tabindex="-1">Target Values, Outcomes &amp; Metrics <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#target-values-outcomes-metrics" aria-label="Permalink to &quot;Target Values, Outcomes &amp; Metrics&quot;">​</a></h4><p>SOPs and SOP Sequences are rulesets with distinct values that correlate directly to the tasks and activities they are meant to guide. An SOP may define certain <strong>target values</strong> that can be achieved by a <em>single</em> task, such as the spacing of plants or the flow-rate of an applied input. These will often differ from the <strong>observed values</strong> that are recorded upon the task's completion. Target values can also be assigned to intervals and deviations between <em>multiple</em> tasks, such as elapsed time or changes in soil moisture, temperature levels, or crop height. Finally, there can also be target and observed values for <strong>the total outcome of a given crop and its associated activities</strong>, such as the total yield, days-to-maturity (DTM), or more qualitative attributes like the crop's moisture density or coloration. Beyond individual crops, values can also be aggregated to represent a particular crop type, seasonal harvest, or multi-year environmental impacts.</p><p><strong>Deviation values</strong> between the target and observed values can be used to judge how closely a set of activities adhered to their respective SOPs. They can also indicate the overall efficacy of a given SOP, or a modified version of an SOP versus its original. This provides a <strong>metric</strong> by which to judge SOPs themselves. For example, an SOP Sequence for a given crop might prescribe that flame weeding occur 6 days after rotary hoeing, but an alternate version of the Sequence changes that to 10 days after hoeing. As a result, the incidence of pests where the modified Sequence was used goes down by some quantifiable rate, say 15%, when compared to the rate of incidence where the original Sequence was used. That may be a valuable insight if it can be observed consistently under similar conditions. It may even be possible to perform a constrained optimization function on all of the variables to determine the optimal number of days under various conditions or for a desired outcome.</p><p>Any of these value types – targeted, observed, or deviation – can feasibly be visualized on the Farm Flow Board. A sort of positive feedback loop may thus emerge whereby SOPs become self-correcting in a sense. Perhaps even greater insight could be gleaned from the way an SOP's metrics trend better or worse given certain modifications, either in isolation or as a whole, sparking a vibrant exchange of SOPs and Sequences among farmers experimenting with different versions.</p><h4 id="version-control-system" tabindex="-1">Version Control System <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#version-control-system" aria-label="Permalink to &quot;Version Control System&quot;">​</a></h4><p>To reap the full potential of such metrics, it is critical that SOPs implement a <strong>version control system (VCS), with the ability to store, traverse, branch, and restore the version history</strong>. This applies not only to individual SOPs, but to Sequences of SOPs, where two Sequences may share the exact same SOPs in the exact same order, but may yet differ in which versions of those SOPs it includes, even if just one SOP differs.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/farm-flow-strategy.html#fn1" id="fnref1">[1]</a></sup></p><h4 id="sop-studio-marketplace" tabindex="-1">SOP Studio &amp; Marketplace <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#sop-studio-marketplace" aria-label="Permalink to &quot;SOP Studio &amp; Marketplace&quot;">​</a></h4><p>In future development, users might be provided with a <strong>SOP Studio</strong> for creating, modifying, and updating their SOPs and Sequences based on previous crops and experience, with the full range of benefits a VCS can provide. Paradigms for how to graphically represent version histories and empower users to perform complex operations on them are already well-established, from <a href="https://git-scm.com/" target="_blank" rel="noreferrer">Git</a> to <a href="https://support.google.com/drive/answer/2409045" target="_blank" rel="noreferrer">Google Docs</a>. This may not be achievable in the first few stable iterations of Farm Flow, but can be anticipated and accommodated by incremental development. As an initial step that can preserve rudimentary version history from the very start, <a href="https://farmos.org/model/type/term/" target="_blank" rel="noreferrer">farmOS Taxonomy Terms</a> (or a similar taxonomic data structure) could be used to model SOPs and Sequences as two distinct vocabularies that can be stored with their associated crop plans. The actual SOPs themselves, meaning the specific set of rules and target values assigned to each term, can be embedded as PDF files or plain text, not necessarily as structured data. That granularity of detail can be added later, but it is far more important that a chain of history be established from the very start.</p><p>By establishing that SOPs and Sequences are algorithms and data, <em>defined and owned by their users</em>, they could also be exchanged in a sort of <strong>SOP Marketplace</strong>. This is where the metrics for certain SOP versions may potentially become even more valuable. Prior to sharing the rulesets and target values for SOPs, their metrics can be shared with other users as a potential selling point. These metrics could even be compared and verified from the aggregated data of multiple users without exposing original or sensitive data. Less competitive use cases could be envisioned where such metrics are shared cooperatively within trusted communities of users.</p><h4 id="case-study-ravelry-as-a-marketplace-of-user-defined-algorithms" tabindex="-1">Case Study: Ravelry as a Marketplace of User-Defined Algorithms <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#case-study-ravelry-as-a-marketplace-of-user-defined-algorithms" aria-label="Permalink to &quot;Case Study: Ravelry as a Marketplace of User-Defined Algorithms&quot;">​</a></h4><p>It may seem like a remote comparison at first, but the knitting website <a href="https://www.ravelry.com/tour/getting-started" target="_blank" rel="noreferrer">Ravelry</a> provides an interesting case study as a parallel to the SOP Studio and Marketplace concept.</p><p><img src="https://www.runrig.org/ravelry-maxine-hot-water-bottle-cover.png" alt=""></p><p>Ravelry is an online community and marketplace for sharing and selling knitting and crochet patterns. Patterns can be searched by category, tags or favorite pattern creators, then sorted by various ranking criteria or metadata. Patterns can be saved to PDF or read as rich text directly from the website in <a href="https://www.craftyarncouncil.com/standards/knit-chart-symbols" target="_blank" rel="noreferrer">standard knitting notations</a>, along with diagrams, images, and video to illustrate various techniques. Some patterns are free, while others can range in price. Once purchased, each pattern is added to the user's personal library where they can upload pictures and notes in order to record their experience using the pattern. Users can choose to show off the results of their handiwork by posting their pictures, ratings, and reviews, all of which link to and are displayed on the pattern's info page. Ravelry brokers these exchanges for a percentage of each pattern's sale price, which is their primary revenue stream. The company is notably small yet dominant among knitters from North America and Europe, as <a href="https://idlewords.com/about.htm" target="_blank" rel="noreferrer">Maciej Ceglowski</a> of Pinboard <a href="https://www.youtube.com/watch?v=5Vt8zqhHe_c&amp;t=1862s" target="_blank" rel="noreferrer">remarked as early as 2013</a>:</p><blockquote><p>Ravelry is a great example of a husband and wife team that eventually grew into a small company. Every once in a while a startup in Silicon Valley gets cocky and tries to take down Ravelry and take over the "knitting vertical," as they call it. About six months later they get their ass handed to them in a beautifully crocheted little bag with a bow, because Ravelry is secretly a <em>social network</em> and not just a place to exchange patterns.</p></blockquote><p>The obvious parallel is the way patterns are exchanged, which mirrors the method proposed above for SOPs. Perhaps more importantly, however, Ravelry's story illustrates how a very strong enterprise can be built up without Venture Capital or by scaling to Silicon Valley proportions; this was the underlying intent of Ceglowski's whole presentation (hence the title: "Barely Succeed – It's Easier!"). The key difference in Ceglowski's view (and ours) is that the company's leadership identified strongly with the community they were aiming to serve from the very start. Thereafter they deliberately encouraged the health and growth of that community. It is the critical factor in their continued success and why they remain the go-to source for knitters to this day.</p><h2 id="actively-promote-data-portability" tabindex="-1">Actively Promote Data Portability <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#actively-promote-data-portability" aria-label="Permalink to &quot;Actively Promote Data Portability&quot;">​</a></h2><p>Farm flow should not only enable but actively <em>encourage</em> users to import and export their data between Farm Flow and other platforms. This includes uploading and downloading data as flat files (CSV, JSON, YAML, etc), but also through networked API services. Such services could be used to provide users with an OAuth-enabled setup "wizard" that allows one-time permission grants to transfer data, or even with continual syncing services between one or more devices.</p><h3 id="benefits" tabindex="-1">Benefits <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#benefits" aria-label="Permalink to &quot;Benefits&quot;">​</a></h3><p>Fully automated, user-facing features for syncing and transferring data over the network are by no means trivial. They may not be practical to achieve in a first stable release or for several iterations after that; however, there are both short- and long-term benefits to adopting portability as a design mandate from the offset, especially when it comes to establishing a data model and migration policy for the first stable release. The benefits can be separated into three general categories, as they pertain to Farm Flow:</p><ol><li>User freedom will be enhanced, including their freedom to try Farm Flow in the first place, due to lower up-front switching costs and alleviated concern over vendor lock-in should they ever choose to leave.</li><li>Farm Flow itself will be less susceptible to vendor lock-in by third-party libraries and services, as well as hosting providers.</li><li>New synergies can be activated within the wider ecosystem of free software platforms, which can diffuse the costs of development and introduce complementary services that boost Farm Flow's appeal.</li></ol><p>It is all the more critical to capitalize on these benefits in order to fully realize the gains of free and open source software as a development strategy. This can be taken even further to the concept Cory Doctorow calls <a href="https://www.eff.org/deeplinks/2019/06/adversarial-interoperability-reviving-elegant-weapon-more-civilized-age-slay" target="_blank" rel="noreferrer">Adversarial Interoperability</a>, where robust APIs and other interop tools can be employed against <em>proprietary</em> cloud services to ward off attempts by Big Tech monopolies to further <a href="https://www.eff.org/deeplinks/2019/06/adversarial-interoperability-reviving-elegant-weapon-more-civilized-age-slay" target="_blank" rel="noreferrer">consolidate the market</a> and turn the tide even towards a freer internet.</p><h3 id="heuristics-for-data-portability" tabindex="-1">Heuristics for Data Portability <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#heuristics-for-data-portability" aria-label="Permalink to &quot;Heuristics for Data Portability&quot;">​</a></h3><p>To achieve these benefits, a few rules of thumb can be helpful:</p><ul><li>Data import/export as a first-order feature</li><li>Model Transparency &amp; Schema Consistency</li><li>Compatibility with Industry Standards</li></ul><h4 id="first-order-import-export" tabindex="-1">First-order Import/Export <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#first-order-import-export" aria-label="Permalink to &quot;First-order Import/Export&quot;">​</a></h4><p>Ultimately, users should be able to take data in and out of the application as smoothly as possible, but as an absolute baseline, they should have the option to import and export their data in a simple flat-file format like JSON, YAML, or CSV. To be clear, this is not recommended as a long-term solution for a number reasons: there may be little else they can do with exports other than view it in a spreadsheet, and the trouble of manually formatting data for import may well outweigh the benefits; basic versioning and data migration will prove daunting, with more advanced options like synchronization pretty much off-limits. However, the critical thing is to approach portability as a first-order feature that can be improved upon iteratively with each pre-release.</p><p>First-order import/export can help inform early decisions, leading to greater consistency in the data model, higher fidelity to the user's mental model, and fewer obstacles to data portability later in development. Alpha and beta testers should be active participants in the domain modelling process, creating a deeper understanding and sense of trust between the domain experts (users) and domain modelers (developers). This in turn can lead to further cooperation and stronger commitment over time. A favorite practice in this regard is the "Show Your Spreadsheets!" workshop, where willing participants can their present the spreadsheets they currently or previously used to organize their operations. Farmers can advise developers on their own experience, lessons they've learned, and the critical nuance of various strategies they've tried. In turn, developers can offer advice on ways to structure data more effectively and suggest ways that their spreadsheets can be imported to Farm Flow without the loss of data or any nuance. Ideally, that means less effort on the user's part when it comes to importing and exporting their data. This process can aided in adopting a few techniques from <a href="https://www.domainlanguage.com/ddd/" target="_blank" rel="noreferrer">Domain Driven Development (DDD)</a>, such as the use of a <a href="https://martinfowler.com/bliki/UbiquitousLanguage.html" target="_blank" rel="noreferrer">ubiquitous language</a> and <a href="https://martinfowler.com/bliki/BoundedContext.html" target="_blank" rel="noreferrer">bounded contexts</a>.</p><p>By the time of the very first general release, users should have a reasonably smooth pathway to importing existing data from other platforms into Farm Flow. This is a clear gain in its own right, since it can greatly simplify onboarding, but it also opens up a pathway for interoperability between the platforms farmers were using in the past and those they may wish to use in conjunction with Farm Flow. User-share doesn't have to be a strictly zero sum game, not where complementary platforms are open to collaboration and exploiting separate niches. By its very nature, such an approach especially favors other free software platforms. Meanwhile, users will also be more inclined to migrate to Farm Flow by knowing they always have an escape hatch to export their data at any time, with the prospect of keeping their data synchronized across platforms as a top priority of future development.</p><h4 id="model-transparency-schema-consistency" tabindex="-1">Model Transparency &amp; Schema Consistency <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#model-transparency-schema-consistency" aria-label="Permalink to &quot;Model Transparency &amp; Schema Consistency&quot;">​</a></h4><p>Portability can be made far easier in the long term with a clearly delineated and accurate means of publishing the schemas for critical data objects, both in the form of documentation and APIs that can be accessed programmatically. There are <a href="https://www.runrig.org/posts/farm-flow-strategy.html#other-modelling-schema--ontology-tools">plenty of alternatives</a> for achieving this, but given Farm Flow's elected backend stack of <a href="https://nestjs.com/" target="_blank" rel="noreferrer">NestJS</a>, <a href="https://www.prisma.io/" target="_blank" rel="noreferrer">Prisma</a>, and <a href="https://supabase.com/" target="_blank" rel="noreferrer">SupaBase</a>, we'll make some specific recommendations here that make use of their built-in utilities:</p><ol><li><strong>NestJS OpenAPI Module</strong>: NestJS provides an <a href="https://docs.nestjs.com/openapi/introduction" target="_blank" rel="noreferrer">official OpenAPI module</a>, which can be used to publish documentation of you APIs in the form of a machine-readable <a href="https://swagger.io/docs/specification/v3_0/about/" target="_blank" rel="noreferrer">OpenAPI</a> YAML or JSON document, as well as the <a href="https://swagger.io/tools/swagger-ui/" target="_blank" rel="noreferrer">Swagger UI</a>, hosted for either private or public access on your website. This can be helpful for Farm Flow's internal team, but doubly helpful for third-party developers wishing to connect via RESTful API services.</li><li><strong>Prisma Schema's Data Model Definitions</strong>: For community developers who wish to contribute to Farm Flow, submit a pull request, provide an extension, or merely adapt elements of its data model to their own applications, the ability to view the data model in a typed Data Definition Language (DDL) can be more helpful than the OpenAPI documentation. Of course, other DDLs, TypeScript, or even pseudo-code could be used, but as the chosen ORM for Farm Flow, the <a href="https://www.prisma.io/docs/orm/prisma-schema/overview" target="_blank" rel="noreferrer">Prisma Schema</a> and <a href="https://www.prisma.io/docs/orm/reference/prisma-schema-reference#model" target="_blank" rel="noreferrer">Prisma <code>model</code></a> objects seem like a natural choice.</li><li><strong>Documentation Generator</strong>: Of course, as a free software project, Farm Flow's Prisma Schema should be accessible as the <code>schema.prisma</code> file(s) in its source code repository; however, the ideal location to publish these schemas would be alongside the rest of Farm Flow's documentation. This could also include other API reference material that can be automatically generated directly from the source code as a part of a Continuous Integration or Development (CI/CD) workflow. A <a href="https://www.prisma.io/docs/orm/prisma-schema/overview/generators#community-generators" target="_blank" rel="noreferrer">Prisma community generator</a> is available, <a href="https://github.com/pantharshit00/prisma-docs-generator" target="_blank" rel="noreferrer"><code>prisma-docs-generator</code></a>, which seems to do precisely that, though surely other viable solutions exist as well.</li></ol><h5 id="other-modelling-schema-ontology-tools" tabindex="-1">Other Modelling, Schema &amp; Ontology Tools <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#other-modelling-schema-ontology-tools" aria-label="Permalink to &quot;Other Modelling, Schema &amp; Ontology Tools&quot;">​</a></h5><p>These tools are more generic but may be worth exploring:</p><ul><li><strong><a href="https://json-schema.org/" target="_blank" rel="noreferrer">JSON Schema</a></strong>: A schema definition language for JSON data, written as JSON. <a href="https://swagger.io/specification/" target="_blank" rel="noreferrer">OpenAPI/Swagger</a> uses <a href="https://json-schema.org/blog/posts/validating-openapi-and-json-schema#light-scheme-icon" target="_blank" rel="noreferrer">a dialect of JSON Schema</a> for its own schema definitions.</li><li><strong><a href="https://ajv.js.org/" target="_blank" rel="noreferrer">Ajv</a></strong>: A widely used JavaScript library for JSON Schema validation.</li><li><strong><a href="https://zod.dev/" target="_blank" rel="noreferrer">Zod</a></strong>: "TypeScript-first schema validation with static type inference"</li><li><strong><a href="https://linkml.io/" target="_blank" rel="noreferrer">LinkML</a></strong>: "LinkML is a flexible modeling language that allows you to author schemas in YAML that describe the structure of your data. Additionally, it is a framework for working with and validating data in a variety of formats (JSON, RDF, TSV), with generators for compiling LinkML schemas to other frameworks."</li><li><strong><a href="https://docs.atomicdata.dev/" target="_blank" rel="noreferrer">Atomic Data</a></strong>: "Atomic Data is a modular specification for modeling and exchanging linked data. It uses links to connect pieces of data, and therefore makes it easier to connect datasets to each other, even when these datasets exist on separate machines. It aims to help realize a more decentralized internet that encourages data ownership and interoperability."</li><li><strong><a href="https://www.prisma.io/docs/orm/reference/prisma-schema-reference#model" target="_blank" rel="noreferrer">Cap'n Proto Schema Language</a></strong>: Almost surely overkill, but Cap'n Proto is an Interface Definition Language (IDL) from the creator of Protocol Buffers (protobufs), with a powerful RPC system rooted in <a href="http://www.erights.org/elib/capability/index.html" target="_blank" rel="noreferrer">Capability-based Security</a>.</li></ul><h4 id="industry-standards" tabindex="-1">Industry Standards <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#industry-standards" aria-label="Permalink to &quot;Industry Standards&quot;">​</a></h4><p>Apart from making Farm Flow's own data model and schema more accessible to community contributors and third-party developers, there are a number of industry standards and data models already widely available that can facilitate data portability and reduce overall costs:</p><ul><li><strong><a href="https://farmos.org/model" target="_blank" rel="noreferrer">farmOS Data Model</a></strong> The farmOS project has a well-established open data model that has been used by a diverse range of farms and organizations, inlcuding the USDA/NRCS Soil Survey, the Pennsylvania Association for Sustainable Agriculture (Pasa), Rothamsted Research, the Savory Institute, Bionutrient Food Association, and the the US Forest Services International Programs. That is to say, adoption of the farmOS Data Model can afford <em>tremendous</em> opportunities for portability and collaboration among platforms. It is a generic, flexible, and broadly applicable Entity-Relationship, or ER, model that can be adapted to a wide range of farm settings.</li><li><strong><a href="https://docs.dfc-standard.org/dfc-standard-documentation" target="_blank" rel="noreferrer">DFC Standard</a></strong>: The <a href="https://datafoodconsortium.org" target="_blank" rel="noreferrer">Data Food Consortium</a> publishes semantic data standards related to food and agriculture, currently comprised of a <a href="https://docs.dfc-standard.org/dfc-standard-documentation/semantic-specifications/business-ontology" target="_blank" rel="noreferrer">business ontology</a> and a <a href="https://docs.dfc-standard.org/dfc-standard-documentation/semantic-specifications/product-ontology" target="_blank" rel="noreferrer">product ontology</a> with plans for a production ontology in the near future. There probably wouldn't be a reason to implement either the business or product ontology in Farm Flow, given its current feature requirements, but even before the production ontology is available, it could be worth familiarizing Farm Flow's developers with DFC's approach.</li><li><strong><a href="https://www.fao.org/agrovoc/" target="_blank" rel="noreferrer">AGROVOC</a></strong>: From the UN's Food &amp; Agriculture Organization (FAO): "AGROVOC is a relevant Linked Open Data set about agriculture available for public use and facilitates access and visibility of data across domains and languages. It offers a structured collection of agricultural concepts, terms, definitions and relationships which are used to unambiguously identify resources, allowing standardized indexing processes and making searches more efficient."</li><li><strong><a href="https://naca-data-shapes.github.io/" target="_blank" rel="noreferrer">NALT</a></strong>: "The NACA data shapes project is a project commissioned by the USDA to apply linked data principles to agricultural data."</li><li><strong><a href="https://www.ic-foods.org/" target="_blank" rel="noreferrer">IC-FOODS</a></strong>: Their <a href="https://www.ic-foods.org/produce-data" target="_blank" rel="noreferrer">Produce Data Project</a> provides "an informational framework and data guidelines to increase the consistency of naming and data conventions to aid smaller producers and producer networks in becoming 'wholesale ready.'" As with the DFC Standard, this might not be strictly relevant to Farm Flows use cases, but could offer some helpful examples.</li></ul><p>Many other relevant standards and protocols exist which can be recommended upon request, suited to match more specific criteria.</p><h3 id="compatible-software-projects-organizations" tabindex="-1">Compatible Software Projects &amp; Organizations <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#compatible-software-projects-organizations" aria-label="Permalink to &quot;Compatible Software Projects &amp; Organizations&quot;">​</a></h3><p>The following free software projects and organizations may offer the opportunity for fruitful collaborations with Farm Flow:</p><ul><li><strong><a href="https://brinjel.com/en/" target="_blank" rel="noreferrer">Brinjel</a></strong>: Brinjel (formerly Qrop) is a free software project sponsored by <a href="https://latelierpaysan.org/" target="_blank" rel="noreferrer">L'Atelier Paysan</a> and as a web-based tool for visualizing crop plans in a Gantt-style chart, is probably the closest free software analog to Farm Flow's intended use case.</li><li><strong><a href="https://www.litefarm.org/" target="_blank" rel="noreferrer">LiteFarm</a></strong>: "LiteFarm is a free and open source farm management tool made for current and aspiring sustainable farms. It was built by farmers and researchers coordinated by the University of British Columbia to address many of the challenges in farm management. It’s currently being used to manage farm operations in more than 155 countries."</li><li><strong><a href="https://farmos.org" target="_blank" rel="noreferrer">farmOS</a></strong>: "farmOS is a web-based application for farm management, planning, and record keeping. It is developed by a community of farmers, developers, researchers, and organizations with the aim of providing a standard platform for agricultural data collection and management."</li><li><strong><a href="https://openfoodnetwork.org/" target="_blank" rel="noreferrer">The Open Food Network</a></strong>: OFN is "open-source software to manage online farmers markets," with separate <a href="https://openfoodnetwork.org/find-your-local-open-food-network/" target="_blank" rel="noreferrer">server instances in over a dozen countries</a></li><li><strong><a href="https://www.our-sci.net/" target="_blank" rel="noreferrer">OurSci</a></strong>: Creator of tools such as <a href="https://www.surveystack.io/" target="_blank" rel="noreferrer">SurveyStack</a>, <a href="https://www.soilstack.io/" target="_blank" rel="noreferrer">SoilStack</a>, and the <a href="https://www.our-sci.net/reflectometer/" target="_blank" rel="noreferrer">Our Sci Reflectometer</a></li></ul><p>Additionally, the <a href="https://goatech.org" target="_blank" rel="noreferrer">Gathering for Open Agricultural Technology</a>, or GOAT, is an active and thriving community of practice, comprised of volunteer members across industry, government, and academia. The <a href="https://forum.goatech.org" target="_blank" rel="noreferrer">GOAT forum</a>, in particular, is an excellent resource and opportunity for engaging with farmers and open source developers alike. <a href="https://openteam.community" target="_blank" rel="noreferrer">OpenTEAM</a> is an organization that's part of the <a href="https://www.wolfesneck.org/" target="_blank" rel="noreferrer">Wolfe's Neck Center</a> for Agriculture &amp; the Environment. With the possible exception of Brinjel, all of the software projects listed above are active participants in both GOAT and OpenTEAM.</p><h2 id="embrace-software-freedom-as-a-business-model" tabindex="-1">Embrace Software Freedom as a Business Model <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#embrace-software-freedom-as-a-business-model" aria-label="Permalink to &quot;Embrace Software Freedom as a Business Model&quot;">​</a></h2><p>Free software – that is, software that users are free to share, modify, and use however they see fit – can be far more than just an ethos, at least when done with care. It can be a powerful strategy for organizing limited resources and disparate contributors to develop effective tools that can far exceed what's possible with proprietary software. However, it requires putting aside a few assumptions that can spill over from the proprietary models. Some basic guidelines and best practices are provided below, but a more thorough-going exposition of Runrig's methodology can be made available upon request.</p><h3 id="licensing-terms" tabindex="-1">Licensing &amp; Terms <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#licensing-terms" aria-label="Permalink to &quot;Licensing &amp; Terms&quot;">​</a></h3><ol><li><strong>License</strong>: Adopt the GNU Affero General Public License, Version 3 (AGPLv3) for all server and client-side code. This will at least ensure that if any competing instances or forks of Farm Flow are hosted, they must adopt a compatible license and abide by comparable standards of software freedom as the Farm Flow project itself (this is the "copyleft" principle, one that is unsupported by other open source license such as MIT or Apache 2.0). The text of the AGPLv3 should be included at the root of all source code repositories as a <code>LICENSE</code> file.</li><li><strong>Licensed Dependencies</strong>: Wherever possible, if using <a href="https://opensource.org/licenses" target="_blank" rel="noreferrer">dual license</a> or <a href="https://en.wikipedia.org/wiki/Open-core_model" target="_blank" rel="noreferrer">open core</a> software dependencies, favor those components that have a license approved by the <a href="https://opensource.org/licenses" target="_blank" rel="noreferrer">Open Source Initiative</a>. Even if Farm Flow elects to hire managed hosting, there should be a clear pathway to a self-hosted solution without undue cost of refactoring the existing codebase, should the need arise. For instance, refer to <a href="https://supabase.com/docs/guides/self-hosting" target="_blank" rel="noreferrer">Supabase's "Self-hosting" guidelines</a> for the paid services available on their platform that can also be freely self-hosted.</li><li><strong>Trademark &amp; Attributions</strong>: Include the Farm Flow trademark statement in the software user interface, public facing marketing and documentation sites, and in the root directories of software repositories for Farm Flow. Wherever other groups or organizations are attributed – such as Cloudburst, 11th Hour Project, Mad Agriculture, or Runrig – make sure to clearly distinguish their contributions so not to be mistaken for the owner of the Farm Flow trademark or its services.</li><li><strong>Terms of Service &amp; Data Policies</strong>: Advise a lawyer with regard to the adoption of Terms of Service and other service level agreements. They should also take into consideration licensing and trademarks attributions, as previously mentioned, as well as jurisdictional compliance, ethical assurances, or any other data policies you choose to adopt that may be considered legally binding.</li></ol><h3 id="auditing-compliance" tabindex="-1">Auditing &amp; Compliance <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#auditing-compliance" aria-label="Permalink to &quot;Auditing &amp; Compliance&quot;">​</a></h3><ol><li><strong>GDPR Compliance</strong>: Even if Farm Flow never intends to market the service in Europe, <a href="https://gdpr.eu/" target="_blank" rel="noreferrer">GDPR</a> compliance should be adopted as an act of good faith to potential users. If Farm Flow is actively marketed in Europe or analytics are collected for site visitors that do not otherwise register under the Terms of Service, third-party <a href="https://gdprcertification.com/" target="_blank" rel="noreferrer">GDPR certification</a> should be considered as well.</li><li><strong>Ethical Data Use &amp; Assurances</strong>: Adoption of the <a href="https://www.go-fair.org/fair-principles/" target="_blank" rel="noreferrer">FAIR Data Principles</a> or OpenTEAM's <a href="https://openteam-agreements.community/billofrights/" target="_blank" rel="noreferrer">Agriculturalists' Bill of Data Rights</a> is also highly recommended and the projects technical leads and engineers should be familiar with the principles and how they may be implemented. In this regard, Runrig can advise in greater detail and conduct acceptance testing upon request.</li><li><strong>Third-party Security Audit</strong>: At the point of an initial stable release (1.0.0), it is highly recommended that Farm Flow hires a third-party security auditing team, in addition to internal security audits.</li></ol><h3 id="transparency-accessibility" tabindex="-1">Transparency &amp; Accessibility <a class="header-anchor" href="https://www.runrig.org/posts/farm-flow-strategy.html#transparency-accessibility" aria-label="Permalink to &quot;Transparency &amp; Accessibility&quot;">​</a></h3><ol><li><strong>Documentation</strong>: Documentation should include basic instructions and requirements for setting up a local development environment and deploying an independent server instance. Important architectural decisions and style guidelines should also be included, as well as reference material for any external APIs.</li><li><strong>Publishing Documentation &amp; Updates</strong>: At minimum, developer documentation should be co-located with its relevant source code repositories, with <code>README</code> and <code>CHANGELOG</code> files placed at the repositories' root directories, written in either Markdown or plain text. Additional pages can be included in a clearly marked subdirectory, such as <code>docs/</code>. Ideally, documentation should also be rendered to an independent website by the time of a first stable release (1.0.0), either as a subsection of Farm Flow's marketing site or as a subdomain. Details from the <a href="https://keepachangelog.com/" target="_blank" rel="noreferrer">changelog</a> can be included in release notes, depending upon distribution method.</li><li><strong>Community Guidelines</strong>: Along with the <code>README</code>, <code>CHANGELOG</code>, and <code>LICENSE</code> files, documentation should also include a <code>CONTRIBUTING</code> file, a <code>CODE_OF_CONDUCT</code> (CoC), and other helpful information for potential contributors. These should indicate where bug reports and other technical issues can be opened, as well as more informal discussion topics and inquiries. The <a href="https://www.thegooddocsproject.dev/" target="_blank" rel="noreferrer">Good Docs Project</a> has a wide array of guidelines, templates, and articles that can help in this matter. The <a href="https://www.contributor-covenant.org/" target="_blank" rel="noreferrer">Contributor Covenant</a> is also an excellent CoC that can be adopted to promote healthy community relationships.</li></ol><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>The complex relationship between different versions of SOPs and SOP Sequences could be represented internally as a <a href="https://en.wikipedia.org/wiki/Directed_acyclic_graph#Genealogy_and_version_history" target="_blank" rel="noreferrer">directed acyclic graph (DAG)</a>, which is how <a href="https://git-scm.com/" target="_blank" rel="noreferrer">Git</a> performs version control, or as a <a href="https://en.wikipedia.org/wiki/Merkle_tree" target="_blank" rel="noreferrer">Merkle Tree</a>, such as how <a href="https://en.wikipedia.org/wiki/Merkle_signature_scheme" target="_blank" rel="noreferrer">cryptographic hash-based signatures</a> are constructed or how <a href="https://en.wikipedia.org/wiki/Content-addressable_storage" target="_blank" rel="noreferrer">content-addressing</a> is performed in systems like <a href="https://ipfs.tech/" target="_blank" rel="noreferrer">IPFS</a> and <a href="https://ipld.io/" target="_blank" rel="noreferrer">IPLD</a>. However, these are details that need not be exposed to the end user. <a href="https://www.runrig.org/posts/farm-flow-strategy.html#fnref1" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Federated Municipal Platforms]]></title>
        <id>https://www.runrig.org/posts/federated-municipal-platforms.html</id>
        <link href="https://www.runrig.org/posts/federated-municipal-platforms.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2025-10-09T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[A federated municipal platform, or FMP, is a communally owned & controlled digital platform, enabling a regional foodshed or bioregion to manage its own land, resources, and labor according to its own needs. It can host a range of free software applications & services, from dedicated food & agricultural software to generic productivity apps, all determined by a local municipality of users. As a federated platform, it can simultaneously cooperate with other community-based platforms to share resources and contribute to global solidarity efforts.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Federated Municipal Platforms</h1><p><strong>A fundamental design pattern</strong></p></header><div style="position:relative;" class="vp-doc _posts_federated-municipal-platforms" data-v-e6f2a212=""><div><blockquote><p>It would be fine if freedom were as easy as this, that man was naturally free. But it is not true. Freedom is the product, not of the instincts, but of social relations themselves. Freedom is secreted in the relation of man to man.</p><p>— Christopher Caudwell, <em>Studies in a Dying Culture</em> (1938)<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn1" id="fnref1">[1]</a></sup></p></blockquote><p>As a design methodology, the Runrig Plan prioritizes organic design elements that can evolve and that are <em>necessarily</em> enmeshed within a broader ecosystem of digital and social technologies, the majority of which are outside the designer's control. I've tried to distill this down to a simple maxim: <em>ecology over architecture</em>. This is meant to inoculate against a tendency in software to fixate on the latest "tech stack," whether that's blockchain, neural networks, or whatever database happens to be the current fad. I don't mean to eschew the notion of architecture altogether; it just shouldn't represent a hard boundary, demarcating the totality of the design space. Architecture must yield to the greater ecology of the system, which knows no bounds; so it must become less determinate, less mechanistic, more permeable; good architecture must be able to float.</p><p>The <strong>federated municipal platform</strong> is intended to be one such architectural pattern, one that will play a central role in many of the systems I hope to build with Runrig.</p><h2 id="a-note-to-the-reader" tabindex="-1">A Note to the Reader <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#a-note-to-the-reader" aria-label="Permalink to &quot;A Note to the Reader&quot;">​</a></h2><p>This article should serve primarily as a design document, and so the reader is encouraged to move between various top-level sections of the page to their specific areas of interest. My hope is you'll be able to get a concise overview of the architecture even if you only read the first section of definitions, although without reading further, you may not be convinced of its benefits nor fully apprised of the means by which it aims to achieve them. Hopefully those details will emerge and convince you the further you go.</p><p>The document is intended for a general audience, so that a thorough-going knowledge of food sovereignty, software design, or political theory is not strictly required. Footnotes will sometimes offer helpful background for beginners on concepts like server federation, or alternately, they may provide technical details that may only appeal to specialists; hopefully the difference will be readily apparent.</p><h2 id="some-definitions" tabindex="-1">Some Definitions <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#some-definitions" aria-label="Permalink to &quot;Some Definitions&quot;">​</a></h2><p>In brief, a federated municipal platform, or <strong>FMP</strong>, is a communally owned and controlled digital platform, enabling a regional foodshed or bioregion to manage its own land, resources, and labor according to its own needs.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn2" id="fnref2">[2]</a></sup> It can host a range of free (or <a href="https://www.gnu.org/philosophy/free-sw.html" target="_blank" rel="noreferrer"><em>libre</em></a>) software applications and services, from dedicated food and agricultural software like <a href="https://farmos.org/" target="_blank" rel="noreferrer">farmOS</a>, <a href="https://www.core-pos.com/" target="_blank" rel="noreferrer">CORE-POS</a>, or <a href="https://coopcycle.org/" target="_blank" rel="noreferrer">CoopCycle</a>, to generic productivity apps like <a href="https://etherpad.org/" target="_blank" rel="noreferrer">Etherpad</a>, <a href="https://nextcloud.com/" target="_blank" rel="noreferrer">Nextcloud</a>, <a href="https://www.getgrist.com/" target="_blank" rel="noreferrer">Grist</a>, all of which will be determined by a local municipality of users. As a federated platform, it can join a network of FMPs, or similarly community-based platforms,such as the <a href="https://openfoodnetwork.org/" target="_blank" rel="noreferrer">Open Food Network</a> and <a href="https://grownby.com/" target="_blank" rel="noreferrer">GrownBy</a>. Within this cooperative network, platform members can then exchange local knowledge and resources with like-minded people in distant food communities, and contribute to global solidarity efforts, all without corporate intermediaries and rent-seekers. Webhooks or bridge services can still automate communications with proprietary platforms, like Shopify or Stripe, so that users don't have to double- or triple-enter information every time their product catalog is updated or inventories rise and fall. Critically, however, even in such cases when FMPs may interact with external, proprietary systems like corporate clouds, the data still originates with the community that produces it, and thus it always remains under their complete control.</p><p>To illustrate its finer details, a federated municipal platform can be dissected into its three constituent terms, then inspected more closely by defining what it means to be a <em>platform</em>, to be <em>municipal</em>, and to be <em>federated</em>.</p><h3 id="platform" tabindex="-1">Platform <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#platform" aria-label="Permalink to &quot;Platform&quot;">​</a></h3><p>As a <strong>platform</strong>, an FMP will host a suite of software applications and network services, like so many of the "cloud" platforms we already interact with every day (e.g., Amazon, Facebook, Airbnb, Netflix). There may be only one such service visible to users, or it might be several distinct applications, but they should be closely integrated and able to communicate with each other. In this regard, it will be comparable to the way Google Calendar, Drive, Docs, Sheets, and Gmail all function as separate apps in their own right, while they are simultaneously integrated as single, cohesive platform. Farmers, food workers, and other community members will access these services via dedicated mobile apps, browser-based web apps, possibly even remote sensors or on-board displays in tractors and other vehicles.</p><h3 id="municipal" tabindex="-1">Municipal <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#municipal" aria-label="Permalink to &quot;Municipal&quot;">​</a></h3><p>As a <strong>municipal</strong> platform, FMP user-members will share collective ownership and control of its services, along with certain responsibilities to maintain and improve it.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn3" id="fnref3">[3]</a></sup> How exactly those services and their maintenance are governed will be up to the user-members collectively, but they should adhere to democratic principles or some sort of consensus procedure. Members will therefore have to get to know one another, if they don't already, either remotely or in person. To keep this from becoming too unwieldy or over-bureaucratized, it will require at bare minimum a few 10s of members, perhaps 100s, but ideally not beyond a few 1,000s or at most 10,000s. Ideally all members will live and work within relatively close proximity to one another, so that the platform represents a regional demographic, foodshed, or bioregion. In the absence of geographic closeness, the membership ought to share some other material interest or concern – beyond the platform itself – to ensure their long-term commitment to each other's mutual success and well-being.</p><h3 id="federated" tabindex="-1">Federated <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#federated" aria-label="Permalink to &quot;Federated&quot;">​</a></h3><p>As a <strong>federated</strong> platform,<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn4" id="fnref4">[4]</a></sup> each FMP will be capable of connecting with other platforms just like it. With some due diligence, it could even connect to platforms that are <em>not</em> so much like itself, like standard payment processors (PayPal, Cash App, Stripe), proprietary sales platforms (e.g., Shopify, Clover POS, Squarespace), or corporate cloud storage services (e.g., iCloud, Dropbox, Airtable). Perhaps most importantly, this means users aren't restricted from joining more than one platform, switching between them, or leaving the platform entirely. Their data can easily follow them with just a simple authorization process, whenever they choose. In other words, you're not forced to stay put or move to whatever app has hold of your data; your data will always come with you. Similarly, sharing your data doesn't force those you share it with to switch to your platform or preferred service.</p><h2 id="political-implications" tabindex="-1">Political Implications <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#political-implications" aria-label="Permalink to &quot;Political Implications&quot;">​</a></h2><p>These terms import a relatively neutral surface-level meaning, which speaks directly to their function. Granted, other terms might denote more or less the same functionality, but I chose these three terms purposely, because they add further political connotations I wish to imply as well. I'll make those politics explicit here because I don't want my intentions to be misconstrued. You can feel free nonetheless to skip to the <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#social-architecture-software-ecology">next section</a>, if you just want get on with the nuts and bolts of how FMPs work.</p><p>Perhaps the closest parallel encapsulating most of what I'm trying to infer with these concepts – although not so much as a <em>digital</em> platform, to my knowledge, but as a <em>political</em> platform – is Cooperation Jackson in Mississippi. Kali Akuno, one of their founders and a frequent spokesperson, rejects what he calls "entities that exist to press for benefits within the capitalist system," or what I allude to below as <em>economism</em> or <em>utopianism</em>. Cooperation Jackson strives towards a form of <a href="https://blacksocialists.us/dual-power-map" target="_blank" rel="noreferrer">dual power</a> by establishing a revolutionary base of socio-economic power, not as a form of escapism but as a direct challenge to the existing capitalist order. I would recommend that FMPs endorse the five <strong>Basic Principles of Class Struggle or Class Conscious Cooperatives</strong>, as laid out by Akuno in his <a href="https://cooperationjackson.org/announcementsblog/buildingclassconsciouscoops" target="_blank" rel="noreferrer">2023 May Day proclamation</a>.</p><h3 id="what-kind-of-platform" tabindex="-1">What Kind of Platform? <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#what-kind-of-platform" aria-label="Permalink to &quot;What Kind of Platform?&quot;">​</a></h3><p>The FMP borrows much of its underlying socioeconomic model from <a href="https://platform.coop" target="_blank" rel="noreferrer">platform cooperatives</a>. In recent years, social theorists like Trebor Scholz, Nathan Schneider, and others have proposed platform cooperativism as a way to counteract the dominant paradigm of <em>platform capitalism</em>. The latter form is well represented by the likes of Amazon, Google, Facebook, Uber, etc., platforms we're accustomed to interacting with on a daily basis. To find a real-world exemplar of a platform co-op, we can look to <a href="https://colab.coop/work/upandgo/" target="_blank" rel="noreferrer">Up&amp;Go</a>. They're a workers' co-op of professional home cleaners, who own and operate the web platform where their customers register, schedule services, and pay for everything on the same site. Platform co-ops are most often thought of as business platforms of this sort, although other examples exist, like the social media site <a href="https://wiki.social.coop/wiki/Main_Page" target="_blank" rel="noreferrer">social.coop</a>.</p><p>A common critique of co-ops, particularly those engaged in commerce, is that even when they promote virtuous behavior <em>internally</em>, such as egalitarianism or free association among fellow workers, they still must survive within markets dominated by capital interests. In order to succeed, therefore, co-ops can be impelled to reproduce capitalistic forms of exploitation <em>externally</em>, even if they don't intend it. To guard against such tendencies, some co-ops pledge to uphold the <a href="https://ica.coop/en/whats-co-op/co-operative-identity-values-principles" target="_blank" rel="noreferrer">7 Cooperative Principles</a> to maintain solidarity with other co-ops, trade unions, and the community at large; however, adherence to these principles is strictly voluntary in most jurisdictions, with little or no enforcement.</p><h3 id="a-municipalist-platform" tabindex="-1">A Municipalist Platform <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#a-municipalist-platform" aria-label="Permalink to &quot;A Municipalist Platform&quot;">​</a></h3><p>In contrast, FMPs should skew a bit closer to the "civic platforms" put forth in James Muldoon's <a href="https://www.techwontsave.us/episode/97_envisioning_platform_socialism_w_james_muldoon" target="_blank" rel="noreferrer"><em>Platform Socialism</em></a>. Muldoon takes inspiration from two early 20th century projects of socialist construction, namely G. D. H. Cole's theory of guild socialism and Otto Neurath's model of economic planning. A wider membership base for FMPs, established not only upon commerce but other equally important social relations, will hopefully afford opportunities for more civic-minded programs to develop. To be sure, commerce will be a key function of the FMP, and so it risks being co-opted or "economized" in just the same way as co-ops; however, membership and participation in an FMP should not be predicated on a person or group entering into a formal professional relationship with other members, so long as they demonstrate their commitment to the community.</p><p>Ultimately, that's why the FMP is also a municipal or <em>municipalist</em> platform, in the sense of Murray Bookchin's <a href="https://social-ecology.org/wp/1999/08/thoughts-on-libertarian-municipalism/" target="_blank" rel="noreferrer">libertarian municipalism</a> or the <a href="https://www.opendemocracy.net/en/can-europe-make-it/which-municipalism-lets-be-choosy/" target="_blank" rel="noreferrer">New Municipalism</a> movement exemplified by groups like <a href="https://barcelonaencomu.cat/" target="_blank" rel="noreferrer"><em>Barcelona En Comú</em></a> and <a href="https://www.fearlesscities.com/" target="_blank" rel="noreferrer">Fearless Cities</a>. Membership should be extended even to people who may seldom login to the platform itself, if ever at all, but who still maintain strong social bonds with the rest of the group or play a role in the community. This will require some combination of careful vetting, targeted recruitment, popular education, and continually active engagement between members to ensure it remains an inclusive body while not falling prey by moneyed interests or bad faith actors.</p><p>In the long run, only constant vigilance can fully safeguard against this and other forms of moral co-optation, but expanding the sphere of participation can at least mitigate the risk of this form of "co-op co-optation" by market forces specifically. That said, a platform might be a municipalist cooperative, like Cooperation Jackson, and I welcome that. I differentiate to spur greater vigilance, but I nevertheless full-heartedly endorse co-operatives that maintain that spirit.</p><h3 id="a-federalist-platform" tabindex="-1">A Federalist Platform <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#a-federalist-platform" aria-label="Permalink to &quot;A Federalist Platform&quot;">​</a></h3><p>Likewise, municipalism should not be mistaken for provincialism, and so the FMP must be a federated – or even a <em>federalist</em> – platform too. I say <em>federalist</em> not in the republican sense, as Alexander Hamilton might have used it, but in the long-held <a href="https://theanarchistlibrary.org/library/what-do-anarchists-mean-by-federalism" target="_blank" rel="noreferrer">anarchist sense of federalism</a>.</p><p>I would only qualify that I don't have in mind the more "utopian" aspects of federalism, often associated with mid-19th century thinkers like Pierre-Joseph Proudhon or James Guillaume. Rather, I would point to much later anarchist projects of the 20th and 21st century, which certainly developed out of utopian socialism but took an explicitly internationalist position in opposition to utopianism.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn5" id="fnref5">[5]</a></sup> Specifically, I would point to the <a href="https://ocalanbooks.com/#/book/democratic-confederalism" target="_blank" rel="noreferrer">Democratic Confederalism</a> of Abdullah Öcalan, which forms the theoretical and constitutional basis for the <a href="https://rojavainformationcenter.org/2023/12/aanes-social-contract-2023-edition/" target="_blank" rel="noreferrer">DAANES</a> of Northeast Syria, a.k.a. Rojava. Their program is emphatically internationalist, while also firmly rooted in social ecology and the municipalist principles of Bookchin, who significantly influenced Öcalan's ideas.</p><p>This sense of federalism harmonizes quite well with the sense of federated server architecture, which I see as a gradated and flexible blend of distributed computing and central coordination.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn4" id="fnref4:1">[4:1]</a></sup> Federation enjoys the benefits of a large, cohesive network, while allowing a tremendous amount of flexibility through localized fine controls. So long as some key protocols are observed, groups of varying size and configuration can still unite their efforts and share resources, without sacrificing any of their diversity.</p><h2 id="social-architecture-software-ecology" tabindex="-1">Social Architecture, Software Ecology <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#social-architecture-software-ecology" aria-label="Permalink to &quot;Social Architecture, Software Ecology&quot;">​</a></h2><p>From a technical standpoint, very little about this architecture is brand spanking new. Prior art exists in separate examples from federated social media, platform cooperatives, and digital democracy tools like <a href="https://decidim.org/" target="_blank" rel="noreferrer">Decidem</a>, <a href="https://pol.is/home" target="_blank" rel="noreferrer">Polis</a>, and <a href="https://democraciaos.org/en/" target="_blank" rel="noreferrer">DemocraciaOS</a>. What I hope distinguishes FMPs is the combination of these patterns with an organizing model that will make essential software services accessible and affordable – specifically for the food and farming communities that need them most – while also being sustainable for the IT professionals, like myself, who ultimately design, build, deploy, and maintain those services.</p><p>Federated municipal platforms are meant to serve as a <em>social architecture</em>, blending digital and social technologies through a comprehensive approach to design. To borrow from Ivan Illich, FMPs will favor digital or social components that can be said to be <em>convivial tools</em>:</p><blockquote><p>Tools foster conviviality to the extent to which they can be easily used, by anybody, as often or as seldom as desired, for the accomplishment of a purpose chosen by the user. The use of such tools by one person does not restrain another from using them equally. They do not require previous certification of the user. Their existence does not impose any obligation to use them. They allow the user to express his meaning in action.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn6" id="fnref6">[6]</a></sup></p></blockquote><p>Finally, in a nod to the organic origins of cybernetics, the FMP is designed to promote a bottom-up <em>software ecology</em>, rather than constructing a top-down software architecture – once again, putting "ecology over architecture."</p><h3 id="unified-data-pipeline" tabindex="-1">Unified Data Pipeline <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#unified-data-pipeline" aria-label="Permalink to &quot;Unified Data Pipeline&quot;">​</a></h3><p>To look at the FMP in terms of the core features users might be interested in, think of it as a <strong>unified data pipeline</strong> that can push and pull data to and from other applications and services.</p><p>For example, if a farmer already has an online store that works well for them and their customers, the FMP won't force them to migrate away from that platform. Instead, it can help them find additional sales outlets that only adds to their sales, while automatically updating their catalog or inventory in multiple stores whenever they update it in their primary store. Or if that's not their jam, it could integrate their store with another tool for managing on-farm production and inventory, so that their stock can be incremented when a harvest activity is recorded or decremented when an order is placed. These could be configured according to how fully automated they wish the process to be, or if they prefer to be prompted to approve updates when a change is detected elsewhere.</p><p>How and where the user interfaces with their data is another aspect meant to provide flexibility. In some cases, an FMP member may never login to a website or app dedicated to that FMP; they might just continue using integrated third-party applications and enjoy the benefits of synchronization. On the opposite end of the spectrum, there could be someone who only wants to login to their FMP from one site to access a comprehensive dashboard for all of their data across multiple platforms. Yet another case are FMP members who can't stand logging in at all and don't use any other tools except email and text messaging; in that case, the FMP can be configured to send out emails or messages to that member, while other members can trigger those messages or send them notifications through the interface of their choosing, like the dashboard or third-party app. In all of these scenarios, even the member who never logs in, they will always enjoy the benefit of a persistent store for all their data that is theirs to individually own and control and that runs on infrastructure that is communally owned and controlled – that is, the FMP itself. At any later date they can choose to access, remove, or transfer their data elsewhere, if they choose to leave or join another platform.</p><p>A core tenet of Runrig's methodology is to provide the <a href="https://en.wikipedia.org/wiki/Glue_code" target="_blank" rel="noreferrer">glue</a> that fits together existing applications, services, and platforms like Lego bricks. I want to consciously avoid starting a new greenfield project every time the existing tools could merely stand to be improved somewhat. How that improvement is made – i.e., how the "glue" gets applied – can play out in various ways. Much of it will depend on the effort required and issues of technical compatibility. The process will also vary significantly depending on whether the existing tool is free &amp; open source software or communal platform, or whether it is a proprietary application or closed cloud platform.</p><h4 id="fmp-x21d4-free-software-fixing-wontfix-issues" tabindex="-1">FMP ⇔ Free Software: Fixing <code>wontfix</code> Issues <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#fmp-x21d4-free-software-fixing-wontfix-issues" aria-label="Permalink to &quot;FMP &amp;#x21D4; Free Software: Fixing `wontfix` Issues&quot;">​</a></h4><p>When the preexisting tool is free or open source software, this might take the form of plugin or extension, which might later be contributed back to the original software as a core feature.</p><p>Sometimes a little more effort might be required, where a separate server is needed to work as an intermediary service that relays and transforms data between two existing tools, or the existing tool and some new piece of functionality. This is actually where FMPs can truly excel, because these kinds of "heavy lifts" are what often get flagged as a <code>wontfix</code> issue by more mature free software projects. That is the tag commonly applied to GitHub issues that represent some feature request or a minor bug that the project's maintainers decide is out of scope for the project and so will not be addressed. Sometimes those issues are pure nuisance – e.g., yet another request to <a href="https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law" target="_blank" rel="noreferrer">add group chat</a> – but sometimes they're valuable features that fall through the cracks for small-scale community projects with limited resources. A Runrig middleware that can run on an FMP could help fill the gap, thereby relieving some of the strain on more mature projects that lack the bandwidth, while serving a niche concern that might not have otherwise been addressed. It lifts all boats by essentially improving the functionality of the ecosystem as a whole, rather than just directing resources to one isolated project.</p><p>In either of these two scenarios, the added functionality can always be reintegrated into previous tools, or taken up and extended as separate projects later on, if enough demand exists to support it. As a part of the software commons, the potential is limitless.</p><h4 id="fmp-x21d4-unfree-software-adversarial-interop" tabindex="-1">FMP ⇔ Unfree Software: Adversarial Interop <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#fmp-x21d4-unfree-software-adversarial-interop" aria-label="Permalink to &quot;FMP &amp;#x21D4; Unfree Software: Adversarial Interop&quot;">​</a></h4><p>An FMP is not limited to working exclusively with free and open source software, but can work with proprietary tools just as well. All that is needed is a public API that the FMP can connect to in some way. In many cases, this kind of interoperability is supported or even encouraged, even among Big Tech platforms. The most straight forward way is through a network request, where the FMP can call the existing service, request some data, or post an update. Some platforms, like <a href="https://apps.shopify.com/" target="_blank" rel="noreferrer">Shopify</a> and <a href="https://developers.squarespace.com/" target="_blank" rel="noreferrer">Squarespace</a>, provide developers with official toolkits to extend the platform's functionality with an app store for plugins and extensions, which can be made to relay data between services or add integrations with third-party applications. At the very least, there is typically some import/export option, which could be automated with a service that could run on the FMP platform itself.</p><p>In cases where the proprietary platform takes a more hostile stance to data portability, or is willfully neglectful of its own users and the wider developer community, we can employ what Cory Doctorow has dubbed <a href="https://www.eff.org/deeplinks/2019/10/adversarial-interoperability" target="_blank" rel="noreferrer">adversarial interoperability</a>:</p><blockquote><p>[Adversarial interoperability is] when you create a new product or service that plugs into the existing ones without the permission of the companies that make them. Think of third-party printer ink, alternative app stores, or independent repair shops that use compatible parts from rival manufacturers to fix your car or your phone or your tractor.</p></blockquote><p>Whether the tactic is one of adversarial interoperability (e.g., via reverse engineering and web-scraping) or benevolent data portability (e.g., via plugins and app stores), the long-term strategy in <em>all cases</em> of interop with unfree software should be a migration path away from the proprietary platform towards a free software alternative, eventually. Users shouldn't be forced into that migration, but they should encouraged. Offering a more gradual migration process should only help with that encouragement.</p><p>The ultimate migration target itself might be a service hosted by the FMP, or it might be a separate free software platform, like <a href="https://openfoodnetwork.org/" target="_blank" rel="noreferrer">Open Food Network</a>, with which the FMP can help establish an automated connection. This strategy goes hand-in-hand with the previous strategy of extending and improving the overall ecosystem of free and open source software. It is a slow-and-steady, piecemeal approach to free software adoption that meets users where they're at, instead of insisting they switch everything all at once. In the meantime, they can still enjoy the immediate, practical benefits of free software, which even limited adoption can afford, while shifting a bit more power away from Big Tech and also lifting some of the burden off free software platforms like Open Food Network.</p><h3 id="two-other-layers" tabindex="-1">Two Other Layers <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#two-other-layers" aria-label="Permalink to &quot;Two Other Layers&quot;">​</a></h3><p>I want to point out here that FMPs are just one layer in the three-layer system I envisage for the Runrig system as a whole. FMPs represent perhaps the most important layer, and they certainly are the most distinct, but there are certain characteristics of the FMP that are only borne out when considered within this context. I addressed these in the <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#three-layers-of-autonomy">initial plan</a> for Runrig and will return to the flesh out other two layers in a separate post, but I'll briefly summarize here the relationship between these layers and their relevant components.</p><p>The three layers themselves can be called:</p><ol><li>Global Data Provider (a.k.a. "One Big Data Union")</li><li>Federated Municipal Platforms (a.k.a. the "Glue Services")</li><li>Local-first Applications (a.k.a. "Bring Your Own Client")</li></ol><p>In a nutshell, these different layers can help ensure a balance between autonomy and equity across individual, local, regional, and global scales.</p><h4 id="global-data-provider" tabindex="-1">Global Data Provider <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#global-data-provider" aria-label="Permalink to &quot;Global Data Provider&quot;">​</a></h4><p>The Data Provider is a global data store of structured, standardized, and self-describing data. Users can be allotted a portion of that storage, which is theirs to own and control, whether they wish to keep it private or share it with other authorized users or share it publicly. This sometimes called a <a href="https://solidproject.org/get_a_pod" target="_blank" rel="noreferrer">personal online data space (PODS)</a> or <a href="https://atproto.com/guides/glossary#pds-personal-data-server" target="_blank" rel="noreferrer">personal data server (PDS)</a>, or they can be referred to more generally a "pod" or <a href="https://internationaldataspaces.org/" target="_blank" rel="noreferrer">data space</a>. The benefit of having structured data of this sort is that the system for storing it can be entirely generic, whether it's farm-related data or an online shopping cart or a collection of restaurant reviews. The data provider can safely host any of these types of data and, with the data owner's permission, distribute it to a multitude of different applications for the owner's own use, or the purpose of sharing with other individuals or services.</p><p>This could be tremendously beneficial to FMPs by offloading some of the burden of storage costs and maintenance, while also offering FMP members with greater flexibility in how to access, share, and store their data. A good example of this is a typical document file stored in a standard format, which can be hosted from a single location but viewed simultaneously from a web browser, a desktop file system, or a mobile app, all with the option to share the document with fine-grained permissions regarding who can view, edit, or leave separate comments.</p><p>Data providers of these sorts can be large or small, run by private companies, non-profit organizations, or governments, and the standards they support can range from the most generic to varying degrees of specificity. An FMP could potentially connect to any sort of data provider and wouldn't be limited to just one, but a global data provider that is collectively owned and controlled – much like the FMP itself, but with a much wider membership – would of course be ideal. That would help to distribute costs more equitably at an international level while creating a massive base for organizing global solidarity efforts. There are a few existing <a href="https://www.adalovelaceinstitute.org/report/legal-mechanisms-data-stewardship/" target="_blank" rel="noreferrer">legal frameworks</a> for how to codify such a shared data system, though I suspect a data trust with some customized provisions for including both individual members and regional platforms themselves as trustees would be advisable.</p><p>Of course, the implementation of such a massive system would take far greater time to fully develop than the FMP itself, but some groundwork could be laid by careful design of the FMPs themselves, with an iterative approach to the deployment of the global data provider.</p><h4 id="local-first-applications" tabindex="-1">Local-first Applications <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#local-first-applications" aria-label="Permalink to &quot;Local-first Applications&quot;">​</a></h4><p>If the global data provider represents a larger scope of collective autonomy, in relationship to the FMP, then local-first applications represent a much smaller, individualized form of autonomy.</p><p>Local-first software is an approach to software design <a href="https://www.inkandswitch.com/essay/local-first/" target="_blank" rel="noreferrer">first postulated in 2019</a> by a group of researchers at Ink &amp; Switch. There's far more to it, but for its relevance to FMPs, the most important aspects of local-first software can be seen as twofold:</p><ol><li>Both the software and the data are always localized and self-contained on each user's personal device, enabling fully offline functionality.</li><li>Data and functionality can still be shared and synchronized across the network for simultaneous, real-time collaboration with peers.</li></ol><p>Local-first applications would be ideal access points for FMP members to interact with their own data. The FMP would function as an "always available" node for synchronizing across devices and between users. Many of the standards and protocols used by the global data provider are well-suited to local-first applications as well. The synergy between the data provider and local-first apps would offer individuals more freedom to join multiple FMPs, switch between them, or leave the network entirely.</p><h3 id="governance" tabindex="-1">Governance <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#governance" aria-label="Permalink to &quot;Governance&quot;">​</a></h3><p>After looking at the ways a data provider could be deployed on a global scale to help diffuse costs, it might be tempting to apply the same rationale to the applications and services that run on the platform. If one global platform cooperative could achieve the same benefits, all while retaining collective ownership and bottom-up control, why go to all the trouble of setting up many, federated, municipal-level platforms?</p><p>But while it may be true that the necessary digital technologies, on their own, could be scaled to such proportions, the same cannot be said for the accompanying social technologies.</p><p>So much of what I've described so far requires on a tremendous amount of introspection and agreement between members of a particular FMP. Since the whole point of the FMP is to give all its members greater sovereignty over their computing systems and food systems alike, the importance of governance to the success of the platform cannot be overemphasized.</p><p>It is for this reason that localized control of the FMP is required. To be effective, control must be exercised through an explicit governing structure, stipulating how decisions are made about its administration and development.</p><h4 id="tradeoffs-scale-vs-scope" tabindex="-1">Tradeoffs: Scale vs Scope <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#tradeoffs-scale-vs-scope" aria-label="Permalink to &quot;Tradeoffs: Scale vs Scope&quot;">​</a></h4><p>I hope I haven't oversold what an FMP can do in practice, as if there's no limit to the degree it can be customized or the number of applications and services it can host. In theory, that's true enough of most computers today, insofar as they are considered <a href="https://en.wikipedia.org/wiki/Turing_completeness" target="_blank" rel="noreferrer">Turing complete</a>, but there are always tradeoffs.</p><p>Of course, the first trade-offs you're likely to encounter will come in terms of material costs to operate the FMP, like the costs of hardware, electricity, and the necessary labor to keep it all running. I'll refer to these as operating or administrative costs. On top of that, FMP members might want to sponsor new features, plugins, or other forms of customization, which we'll call the development costs. If you choose to forgo all development, those costs can be mostly eliminated. When it comes to administrative costs, however, the slope of cost-savings will inevitably bottom out in a long tail before ever hitting zero.</p><p>Then again, the rising slope of administrative costs also tends to level out as usage increases, so long as it is carefully managed. Therefore, if an FMP can recruit more members and development costs remain constant, it can contribute to further cost reductions per member. This is what many startups hope to achieve when they talk about <em>scalability</em>, but as I discussed in <a href="https://www.runrig.org/posts/against-scale.html">my previous article</a>, the gains can be illusory at best and may obscure the more extractive methods of modern platform capitalism.</p><p>The reason for scalability's shortcomings is the same reason an FMP is forced to consider yet another trade-off at this point: increasing membership may only increase administrative costs at a diminishing rate, but it will likely increase the demand for more features and application development. Development costs hardly ever remain constant, especially "at scale," and they can vary farm more than administration costs. In fact, if the functionality expected by users only ever <em>diverges</em> as their numbers increase, costs may even rise exponentially.</p><p>The primary cost-savings of an FMP, unlike cloud capitalist platforms, is that its members can actively promote the <em>convergence</em> of feature expectations. If there is sufficient cohesion, and members can agree on a relatively fixed scope of functionality the FMP will address – i.e., its set of applications, services, and customizations – then that can go a very long ways to keeping even development costs low. The only limiting factor is their ability to reach <em>consensus on the scope of functionality</em> that the FMP will cover.</p><p>In other words, it's all about governance. No one-size-fits-all solution exists, and each FMP will need to determine the scope of what it is feasible, what kind of economic activities it will facilitate, and what aspects of food production and distribution it will manage. To do that, members will first need to decide on what governance structure or consensus process they will adopt. The more the membership's needs and wants overlap with each other, the fewer distinct applications and features will need to be developed and maintained, and the lower per member cost of development and administration will fall.</p><p>Also, by choosing the operational scope carefully, the costs can be further offset by other resources that can be distributed and shared. Beyond the compute resources needed for the platform itself, the FMP can facilitate the management of <a href="https://en.wikipedia.org/wiki/Common-pool_resource" target="_blank" rel="noreferrer">common-pool resources (CPR)</a>, such as trucking and cold storage, in order to lower costs. Similarly, the overall value can increase by pooling resources such as marketing outlets and agronomic knowledge.</p><h4 id="geographic-boundaries" tabindex="-1">Geographic Boundaries <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#geographic-boundaries" aria-label="Permalink to &quot;Geographic Boundaries&quot;">​</a></h4><p>For all of these reasons, the easiest way to achieve equilibrium will most often be the establishment of geographical boundaries. After all, the underlying economic and social dynamics of an autonomous food system should be rooted in place, as I think most people will recognize intuitively. Geographic proximity ensures at least some commonality of material needs and wants, in so far as the same material resources can be brought to bear on a given operation without incurring further transportation costs. By assigning a geographic boundary, it can also help avoid more exclusionary methods of limiting membership, based upon a member's socioeconomic status or upon the self-selecting tendencies that can emerge within a closed sphere of cultural identity.</p><p>How and where the geographic boundaries are determined, however, will still depend heavily upon the specific context. As I stated <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#municipal">above</a>, an FMP will likely require at bare minimum a few 10s of members to be effective, perhaps 100s, but ideally not beyond several 1,000s or at most a few 10,000s. In contrast to the billions of users most venture capital startups aspire to, such differences of scale seem trivial, but they still represent three orders of magnitude. It may not matter much when it comes to <em>managing the scale of administrative costs</em>, but it matters a whole lot in terms of <em>governing the scope of development costs</em>.</p><p>So again, there's no one-size-fits-all solution here, but geography can at least provide a helpful starting point.</p><h4 id="resource-allocation" tabindex="-1">Resource Allocation <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#resource-allocation" aria-label="Permalink to &quot;Resource Allocation&quot;">​</a></h4><p>The main issue of FMP governance – excluding other policies that regard the community but do not require specific changes to how the platform operates – will be in deciding what software it will provide and how to pay for it.</p><p>Such decisions may include:</p><ul><li>Structuring monthly or annual hosting fees among members to pay for the platform's servers and other core utilities.</li><li>Allocating funds to sponsor new features, plugins, or platform customizations.</li><li>Hiring technical assistance providers to support members remotely or on-site.</li><li>Raising additional funds to expand capacity through a dues paying system, public or private grants, crowdfunding initiatives, percentage-based service fees for online sales or other transactions, etc.</li><li>Electing platform members to act as community stewards or moderators, to form working groups, or form governing councils.</li><li>Equitable reapportionment of resources through sliding scale programs, CSA solidarity shares, discounted hosting fees for members, etc.</li></ul><p>See the section below on <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#technical-support">technical support</a> for a slightly more detailed list of the kinds of utilities, development, and other forms of technical assistance that FMP members may elect to hire.</p><h4 id="tool-kits-guidelines" tabindex="-1">Tool-kits &amp; Guidelines <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#tool-kits-guidelines" aria-label="Permalink to &quot;Tool-kits &amp; Guidelines&quot;">​</a></h4><p>There are too many governance models, funding methods, and facilitation tools to address all options here in full. And as I keep saying, plenty of latitude ought to be given to FMP members to decide what works best for them. However, without trying to sway the form of governance an FMP might choose, there are still three resources I recommend to anyone organizing on democratic principles, whatever the nature of their project:</p><ul><li><p><strong><a href="https://www.enspiral.com/" target="_blank" rel="noreferrer">Enspiral</a>:</strong> This cooperative from Aotearoa, New Zealand develops <a href="https://www.loomio.com/" target="_blank" rel="noreferrer">Loomio</a>, free and open source software for online voting, proposal submissions, transparency, and more. They also make the participatory budgeting tool, <a href="https://cobudget.com/" target="_blank" rel="noreferrer">Cobudget</a>, and publish their <a href="https://handbook.enspiral.com/" target="_blank" rel="noreferrer">Enspiral Handbook</a> for others to learn from their experience as a cooperative and a self-governing community.</p><p>Voting tools – including but not limited to the ones that Enspiral offers – could also be hosted on the FMP, although in many cases that probably won't be necessary. For example, I would recommend most groups use Loomio's cloud service, since it supports their cooperative and customization ought not be required.</p></li><li><p><strong><a href="https://communityrule.info/" target="_blank" rel="noreferrer">Community Rule</a>:</strong> A beautifully designed "governance toolkit" by Nathan Schneider. You can start with a <a href="https://communityrule.info/templates/" target="_blank" rel="noreferrer">rule template</a> – e.g., Do-ocracy, Consensus, Elected Board, or Benevolent Dictator – or mix-and-match <a href="https://communityrule.info/library/" target="_blank" rel="noreferrer">rules from the library</a>, then publish and share your own unique set of rules. There's also a PDF version of the <a href="https://communityrule.info/book/" target="_blank" rel="noreferrer">Community Rule book</a> that you can print and share for free. It can be helpful to look at the different configurations as an ongoing decision process, where communities continue to grow, shrink, change, reflect, always evolve, and periodically reset.</p></li><li><p><strong><a href="https://www.jofreeman.com/joreen/tyranny.htm" target="_blank" rel="noreferrer">"The Tyranny of Structurelessness"</a>:</strong> This classic essay by Jo Freeman was first published in 1971. Based on her experience in the women's liberation movement, Freeman argues for the adoption of <em>explicit</em> governing structures, even when in radically decentralized or horizontalized groups, because otherwise <em>implicit</em> governing structures tend to form, with or without anyone's intention. Unspoken hierarchies of that sort can be especially difficult to address once they've formed. They can lead to internal strife, and often perpetuate many of the inequities such "structureless" groups claim to oppose.</p><p>Freeman gives examples of certain governance mechanisms, like sortition and the assignment of a spokesperson, but she doesn't prescribe any one governance structure, nor which mechanisms work best outside of the particular context. In her conclusion, she offers seven <em>Principles of Democratic Structuring</em> which are well worth consideration even if you read nothing else, though I still recommend reading the essay in its entirety. As principles go, they're quite flexible, more like the ideal <em>traits</em> that a democratic body should evince, without stipulating a definite form.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fn7" id="fnref7">[7]</a></sup></p></li></ul><h3 id="technical-support" tabindex="-1">Technical Support <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#technical-support" aria-label="Permalink to &quot;Technical Support&quot;">​</a></h3><p>A final component in this social architecture is the role of software developers and other tech workers, designers, managers, etc. Technical consultants specializing in Runrig FMPs could offer any of the services listed below:</p><ul><li>Initial platform deployment along with basic applications and services.</li><li>Ongoing hosting, maintenance, and system administration for the platform, available on a monthly or annual basis.</li><li>Sponsored development of new features, plugins, middleware, or other forms of platform customization.</li><li>Remote help desk for platform members and community administrators.</li><li>On-site technical assistance in the form of periodic site visits, training sessions, or custom installations of sensors or on-premise servers.</li><li>Facilitation of participatory design, research, or education projects to meet the community's strategic goals.</li><li>General software consultation and technology assessments, à la carte.</li></ul><p>Note that many of the services listed above correspond to specific points of governance I outlined earlier, regarding <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#resource-allocation">resource allocation</a>. These are in effect what those resources represent, broken down in terms of labor, hardware, and energy.</p><p>Technical support may be provided remotely, but if the support workers also live within the community they serve, they may be eligible – in this one case – for membership in the FMP itself – of course, with some reasonable provisions to preclude any conflicts of interest. In all other cases, it must be stressed, support workers <em>will not</em> be offered membership in the FMP, nor be granted rights enjoyed exclusively by FMP members, even if the consultants constitute their own worker cooperative with distinct membership rights thereof.</p><p>This is yet another topic I will need to expand upon in a future article, but I intend FMPs and Runrig's other methodologies to make free software development more sustainable for independent developers like myself. There's no reason this can't go hand-in-hand with developing software tools that respect users' freedom while offering better design and functionality than what's currently available to food communities as free software – even in comparison to the most cutting edge proprietary offerings.</p><h4 id="where-to-find-support" tabindex="-1">Where to Find Support <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#where-to-find-support" aria-label="Permalink to &quot;Where to Find Support&quot;">​</a></h4><p>As a distinctly community-led formation, there is no firm requirement that I or anyone directly connected to Runrig to take part in the establishment of an instance of a <em>federated municipal platform</em>. The FMP is a set of design patterns and an architectural framework, which anyone is free to replicate.</p><p>In fact, if a community has members with the technical knowledge and experience to deploy an FMP themselves, they're welcome to do so. In a wide enough geographical expanse, there ought to be someone with the bit DevOps experience needed to get it up and running. They could do it for hire or on the basis of mutual aid. If someone lacks the experience but is sufficiently motivated to learn, there are people like myself in the wider free software community who would willingly offer guidance so they could introduce that knowledge and expertise into their regional community.</p><p>Nevertheless, remote tech support should be available to provide the expertise to anyone who needs it. In fact, remote support is no less encouraged than local support, so long as it is done <em>for hire</em>, meaning the community retains full ownership of the servers, and a license <a href="https://www.gnu.org/licenses/license-recommendations.html" target="_blank" rel="noreferrer">recommended by the Free Software Foundation</a> is applied to any original software.</p><p>As I stated above, the platform's social architecture is designed to be <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#a-municipalist-platform"><em>municipalist</em></a> in nature, not merely provincial. Likewise, FMPs should form a <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#a-federalist-platform"><em>federation</em></a> of platforms, where each regional FMP can connect to adjacent and overlapping regions and even further afield. <strong>Regional sovereignty must go hand in hand with international solidarity</strong>, because <em>none of us are free until everybody's free</em>, to once again paraphrase Fannie Lou Hamer.</p><p>The free software community, as a global, virtual network of activists and practitioners, should be seen as an ideal gateway for establishing <em>social connectivity</em> with other platforms in distant regions, in addition to the digital network connectivity that allows them to federate. Employing free software engineers and designers from abroad is an excellent way for FMPs to cross-pollinate, share what they've learned, and open up direct channels for dialogue with like-minded communities around the world.</p><h4 id="tech-worker-cooperatives" tabindex="-1">Tech Worker Cooperatives <a class="header-anchor" href="https://www.runrig.org/posts/federated-municipal-platforms.html#tech-worker-cooperatives" aria-label="Permalink to &quot;Tech Worker Cooperatives&quot;">​</a></h4><p>Some local activists and I have begun a project to start an FMP here in our own community of the Hudson Valley and New York City Metro Area. We'll then be able to provide the service to other regions who need that support. Ultimately, we hope to organize a Runrig worker cooperative, comprised of technologists, designers, and advisors. This will complement the digital commons Runrig is building for free software and design artifacts as a dedicated team of people to steward that commons, while also making it easier for others to benefit from its use.</p><p>If you're interested in joining as a worker member, or would like to discuss starting an FMP in your region – or if you're our neighbor in the HV/NYC region and want to pitch in on this one! – don't hesitate to <a href="mailto:jamie@runrig.org" target="_blank" rel="noreferrer">email me</a>.</p><p>Likewise, I encourage other independent software developers and existing cooperatives to seek out partnerships with food workers, farmers, produce distributors, delivery drivers, food rescue organizations, and mutual aid groups to establish an FMP in their own community. If there ever becomes enough demand (🤞🏻), there may be opportunities to offer support contracts to multiple FMPs, as well as for the <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#two-other-layers">two other layers</a> mentioned above.</p><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>The epigraph for this document, which I first came across while drafting it, was penned by the English literary critic, Marxist philosopher, and volunteer for the International Brigades in the Spanish Civil War, Christopher Caudwell. Before those lines could be published, however, Caudwell was killed at the Battle of Jarama in 1937, defending a hill against Franco's fascists, so that his comrades could make a safe retreat.</p><p>At the moment I write this, with the dust just starting to settle on Gaza City, and with ICE brownshirts storming America's cities, his words echo in my ears as an ever-present call for international solidarity. Even more, his deeds stand before me as a reminder that lasting freedom will always be contingent upon a correspondingly steadfast solidarity: <em>none</em> of us can enjoy true freedom unless it is universally shared. It's the same sentiment you can find in the words of <a href="https://stjamesaustin.org/wp-content/uploads/2021/02/Until-I-Am-Free-You-Are-Not-Free-Either-by-FLH.pdf" target="_blank" rel="noreferrer">Fannie Lou Hamer</a> or <a href="https://theanarchistlibrary.org/library/michail-bakunin-man-society-and-freedom#:~:text=I%20am%20truly%20free%20only%20when%20all%20human%20beings,its%20necessary%20premise%20and%20confirmation" target="_blank" rel="noreferrer">Mikhail Bakunin</a>, put into action. Or as Caudwell himself told a friend in 1936 before joining the Spanish People's Army, "their struggle, if they fail, will certainly be ours to-morrow, and, believing as I do, it seems clear where my duty lies." <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref1" class="footnote-backref">↩︎</a></p></li><li id="fn2" class="footnote-item"><p>With Runrig, I plan to work mostly within food and agricultural communities, so I've defined the FMP in familiar terms like "foodshed" and "farmers." There's nothing about this architecture, however, that couldn't be applied to more generic community groups or for different types of economic or social activity. <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref2" class="footnote-backref">↩︎</a></p></li><li id="fn3" class="footnote-item"><p>Collective ownership and control does not apply to purely individualized or personal data, only shared instances of the software running as services on collective infrastructure. Each user's data will be theirs and theirs alone, until they choose to share it with other members of the platform, or with members of the general public; that choice will <em>always</em> be theirs. Instances of the software users choose to run independently as applications on their own personal devices are also theirs to own and control individually. Ownership and control of these running <em>instances</em> of the software, whether they're cloud servers or phone apps, are distinct from ownership and control of the software itself and its source code, which remain parts of the software commons under the GNU Affero General Public License v3.0, or AGPLv3. <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref3" class="footnote-backref">↩︎</a></p></li><li id="fn4" class="footnote-item"><p>Here I mean the technical sense of a <em>federated server architecture</em>. Simply put, that's when servers communicate with other servers as peers, in what can almost be called a peer-to-peer (P2P) architecture, as opposed to the more conventional client-server architecture.</p><p>Some familiar examples of user-facing P2P applications are BitTorrent, Apple Airdrop, or even Bluetooth; these can offer some helpful intuitions about federation for anyone not as accustomed to working with servers. In each of those P2P examples, the peer devices – or "nodes" as they're called – run the same identical software. The software may resemble client software in the way that end users interact with it directly, but it is no longer client software in the truest sense, since each copy of the software is capable of negotiating a connection with any other copy of itself, without the intercession of a distinct server.</p><p>Federated servers are likewise conceived of as a network of peer nodes, but are server nodes in a decentralized <em>network of servers</em>, wherein no single server is distinguished as authoritative over the others. Typically, they are still thought of as clientless or "headless" servers, in that they don't need to take commands from any type of graphical interface or other form of direct user input, nor do they act as "clients" to other servers or vice versa. The federated software that runs on one server is, once again, <em>identical</em> to the software that runs on every other federated peer. A federated server may still continue to act in the role of a traditional server with traditional clients, but those clients are distinct from their federated peers.</p><p>Federation, in this sense, is the pattern that gives its name to the <a href="https://fediverse.info/" target="_blank" rel="noreferrer">Fediverse</a>, most famously represented by Mastodon, the alternative social media app, along with the myriad other <a href="https://delightful.coding.social/delightful-fediverse-clients/" target="_blank" rel="noreferrer">federated apps</a> and <a href="https://delightful.coding.social/delightful-fediverse-experience/" target="_blank" rel="noreferrer">federated services</a> that support some variant of the <a href="https://activitypub.rocks/" target="_blank" rel="noreferrer">ActivityPub</a> protocol. Note that a common (if not essential) feature of nearly all federated applications is an agreed upon protocol or standard for sharing data. That is the contract that federated servers make with each other in order to cooperate while remaining independent.</p><p>As a more mundane example, an email server presents an ideal case of federation combined with the client-server architecture, where the server hosts clients but can also federate with other servers. For instance, you could access your <a href="https://proton.me" target="_blank" rel="noreferrer">Proton</a> email account through the iOS client app on your phone to send an email to a friend's <a href="https://roundcube.net/" target="_blank" rel="noreferrer">Roundcube</a> email address on their own self-hosted server. Proton's email server <em>federates</em>, in essence, with your friend's Roundcube server, via the standard email protocol that both servers share. Then your friend can view the email you sent from their browser, using Roundcube's web client or an independent Android client on their phone, like <a href="https://www.thunderbird.net/en-US/mobile/" target="_blank" rel="noreferrer">Thunderbird</a>. <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref4" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref4:1" class="footnote-backref">↩︎</a></p></li><li id="fn5" class="footnote-item"><p>Starting at least as early as the Spanish Civil War, anarcho-syndicalists of the <a href="https://libcom.org/tags/federacion-anarquista-iberica-fai" target="_blank" rel="noreferrer">CNT-FAI</a> established federated communes as a part of their revolutionary fight against fascism, supported by the International Brigades and a host of left-wing tendencies ranging from libertarian socialists to Trotskyists. <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref5" class="footnote-backref">↩︎</a></p></li><li id="fn6" class="footnote-item"><p>Ivan Illich, <em>Tools for Conviviality</em> (Harper &amp; Row, 1973), 22. Famously, Illich's definition of <em>tools</em> included "all rationally designed devices," such as hand tools, kitchen utensils, industrial machinery, industrial factories themselves, interstate highway highways, and telephone networks. He even included "productive systems for intangible commodities such as those which produce 'education,' 'health,' 'knowledge,' or 'decisions,'" by which he may was likely inferring universities, hospitals, research labs, and public or private administration offices, respectively. <a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref6" class="footnote-backref">↩︎</a></p></li><li id="fn7" class="footnote-item"><p>Again, I encourage anyone who's not already familiar with it to read <a href="https://www.jofreeman.com/joreen/tyranny.htm" target="_blank" rel="noreferrer">"The Tyranny of Structurelessness"</a> in its entirety, but here are her seven <em>Principles of Democratic Structuring</em>, paraphrased for quick for reference:</p><ol><li><strong>Delegation of Specific Authority:</strong> The group selects members to be granted the authority to perform specific tasks on behalf of the group, rather than members self-selecting to assume wide-ranging authority.</li><li><strong>Accountability of Delegates:</strong> Once selected, delegates are held accountable to the group to exercise that authority as the group determines, not arbitrarily by the delegate's discretion.</li><li><strong>Sufficient Distribution of Authority:</strong> Delegate tasks to as many group members as it is reasonable, so authority is exercised through consultation with others, and so more people have a chance how to learn how to perform those tasks.</li><li><strong>Periodic Rotation of Authority:</strong> Delegates should be responsible for a task long enough to gain competence and satisfaction from its performance, but not so long that they become possessive or unwilling to relinquish responsibility.</li><li><strong>Rational Allocation of Authority:</strong> Ability, interest, and reliability with regard to the specific task should be the main criteria for selecting delegates, not popularity. Group members can learn new skills by apprenticing with a delegate, but not being thrust into the delegate position alone.</li><li><strong>Equal Diffusion of Information:</strong> Information should be spread to everyone equally and frequently through proper group channels. Leaving information to circulate haphazardly through the rumor mill can lead to power imbalances and factionalism.</li><li><strong>Equal Access to Resources:</strong> Equipment, information, and skills that the group needs to function should be shared equally among members. If full equality of access is not practical to achieve from the start, then members must be willing to teach, learn, and share whatever they can so they may fully realize it eventually.</li></ol><a href="https://www.runrig.org/posts/federated-municipal-platforms.html#fnref7" class="footnote-backref">↩︎</a></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Hedgerows in the Sky]]></title>
        <id>https://www.runrig.org/posts/hedgerows.html</id>
        <link href="https://www.runrig.org/posts/hedgerows.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2024-05-30T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[In this essay I explore the role of the commons in today's food & data sovereignty movements. I try to explain why the full potential of the commons was seemingly overlooked or studiously ignored by earlier North American movements around sustainable agriculture, local food, free culture, and open source technology.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Hedgerows in the Sky</h1><p><strong>Concerning knowledge enclosures and how they may be truly leveled</strong></p></header><div style="position:relative;" class="vp-doc _posts_hedgerows" data-v-e6f2a212=""><div><p>When I tell people I make open source software for farmers, I'll occasionally hear some variation of the reply, "Why do farmers care whether their software is open source?" The precise response may differ in tone from the genuinely curious to slightly facetious or even outright incredulous. "You don't actually expect farmers to read the source code or build the binaries themselves, do you?" I might have to concede on that last point, but it seems to me that, regardless of how they're expressed, responses of this sort all rely upon the same faulty premise. They assume that farming and information technology represent opposing world views, that their issues and concerns seldom correlate, and if they do it's by sheer accident.</p><p>Lately, I haven't heard this response quite as often as I used to. I attribute this in part to the rise of the closely aligned food sovereignty and data sovereignty movements here in North America. Apart from their shared naming conventions, these two movements and their adjacent tendencies share a belief that the resources we produce, consume, and depend upon each day should be controlled at the community level. That goes the same for food, software, hardware, agricultural inputs, or data. When it comes to what kind of software or farming practices the community employs, or how much food or data is imported into the community — or likewise exported — those decisions ought to happen locally, or at a regional scale appropriate to the task at hand. The power to choose should be decentralized as much as possible, but also more fairly distributed. Put another way, both movements are committed to stewarding common resources, and they don't necessarily put any restrictions on what those resources might be: common land and a knowledge commons are together just <em>the commons</em>, one and the same.</p><p>Unlike more right-leaning libertarian ideologies, which prevail among agriculturalists and technologists alike, proponents of food and data sovereignty do not insist that local control must devolve to the smallest possible unit of autonomy — that is, solitary individuals. Individual autonomy is an important component for food and data sovereignty, but these movements focus their efforts on achieving community control of resources, where social relations are grounded in trust and a shared sense of belonging. On this basis, clear parallels can be drawn between the two movements' practices. For example, you can compare collectivized farm management to cooperative data trusts. Mutual aid food programs, such as free fridges or group buying clubs, arguably have their counterparts in communally run social media networks, such as the open source Mastodon project or its derivative, Hometown, which is even more tailored to small, localized groups of friends.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn1" id="fnref1">[1]</a></sup> Some food co-ops and farm CSAs offer sliding scale prices or solidarity shares in an effort to introduce more equity into their payment structures. In a similar fashion, open source software projects are commonly sponsored through Liberapay, OpenCollective, Ko-fi donate buttons, or other "pay what you can" mechanisms, while remaining free to use for everyone.</p><p>Though the concepts have only recently achieved notoriety in the U.S., food and data sovereignty can trace their origins to several earlier movements that preceded them. Some of their predecessors skew quite differently in ideology, while others do not; some are endemic to the U.S., yet others have gone largely unnoticed here until quite recently, having gained momentum first in the majority world. As I've tried to understand their convergent histories, a few of their forerunners stand out because of their significance to my own journey. I was introduced to food sovereignty by way of my earlier connections to the local food and farm-to-table movements in and around New York City during the 2000s and 2010s. Data sovereignty, also known as information or technological sovereignty, is a comparatively new trend I have seen emerging from older free and open source software (FOSS) communities and the free culture movement.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn2" id="fnref2">[2]</a></sup></p><p>It could be argued that each of these earlier movements reached their apex sometime in the two decades straddling the turn of the millennium. Yet the affinities that are visible today between food and data sovereignty weren't nearly as apparent in their antecedents back then. While notions of collective autonomy can be insinuated from the earlier movements, it wasn't their primary concern, nor was it commonly associated with the political milieu that either of them inhabited. The small farming and local food movements of that era fixated on what was near-at-hand, low-tech, organic, provincial and professedly slow. Meanwhile, the free-culture and open source movements set their gaze on global streams of non-rivalrous information liberated by cutting-edge technology. By virtue of their abstractness alone, these bits of data and code were free to move across borders without restriction, effortlessly and instantaneously. With so little in common, there was rarely any dialogue or collaboration between the two camps.</p><p>Strangely enough, the metaphor of "the commons" was only adopted by the technologists of that earlier era, not by the so-called foodies and locavores. This is in spite of the term's origin as a form of communal land tenure, practiced widely by peasant farmers. It was this apparent contradiction that first got me looking more critically about the relationship between farming and technology. And it only got more puzzling the deeper I looked.</p><p>I've already spent too many hours digging through the relics of early internet subculture and hunting down pay-walled citations on Sci-Hub.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn3" id="fnref3">[3]</a></sup> I've finally resigned to the fact that I'm never going to reach any definitive conclusions, perhaps not even a satisfactory understanding of all this. The more I learn, the more I realize just how my own perspective on these issues has been narrowed — possibly even distorted — by circumstances of time and place. Over the last twenty years, I have alternated between enthusiasm, loathing, and apathy for the cultures that surrounds both food and tech. Here on America's Eastern Seaboard, at the Heart of Empire, the food and tech scenes are never dull; neither their adherents nor their detractors are shy with their opinions; I've certainly clung to a few of my own for too long. But I'm becoming increasingly aware how my very <em>subjectivity</em> has been molded by political narratives that far exceed this moment in both time and place. The conceptual linkages joining food, technology, land, and knowledge run far deeper into history, before human beings even learned to farm. Food, technology, land, and knowledge: they are the prime constituents of culture, are they not? Does a day or even an hour go by when we don't feel their effects?</p><h2 id="the-gathering-for-open-agricultural-technology" tabindex="-1">The Gathering for Open Agricultural Technology <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#the-gathering-for-open-agricultural-technology" aria-label="Permalink to &quot;The Gathering for Open Agricultural Technology&quot;">​</a></h2><p>About a year and a half ago, I sat with a dozen or so engineers, agronomists, designers and soil scientists, clustered around a couple hastily arranged tables. It was an "unconference"<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn4" id="fnref4">[4]</a></sup> session titled "Justice for Nature."<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn5" id="fnref5">[5]</a></sup> Across the wide, high-ceilinged hall and its adjoining patios, three or four similar groups convened on topics ranging from semantic data formats to climate resilience. Two or three people would periodically split off to pursue a tangent idea before rejoining the larger group, while others hung in loose orbit between the scattered tables, occasionally leaning in to pick up the main thread of one conversation or another. Two days earlier we had all converged on the Omega Center in Rhinebeck, NY for the second ever large-scale Gathering for Open Agricultural Technology, or GOAT 2022 for short.</p><p>I had been there for the first such gathering in 2018. It had a profound effect on me, the kind of "found my people" moment you're lucky to have only once or twice in a lifetime. Back then, our talk centered around how best to convince farmers of the benefits of open source software, along with perennial issues like interoperability and design methods. When I arrived this time, I didn't expect a second life-altering event, but in those three days I had witnessed a new shared awareness emerging about the role of the commons in both agriculture and technology. Four years of accelerating climate change, ongoing police violence, supply chain disruptions, housing shortages, and a global pandemic had clearly shifted our attentions.</p><p>It was during the Justice for Nature session that Samuel Oslund, an independent researcher then at the CAPÉ<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn6" id="fnref6">[6]</a></sup> farming cooperative in Île de Montréal, directed the conversation towards the Amish <em>Ordnung</em>. In essence, <em>Ordnung</em> is a code of conduct or rules each community formulates for itself. It does not ban technology outright, but prescribes a selection process that may include evaluation by community elders, probationary trial periods, and group consensus.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn7" id="fnref7">[7]</a></sup> From our superficial understanding, we saw it as a means of socializing technology adoption, with localized control and intent. The entire community took ownership of any externalities (if they could still be called that), and through collective action they could adjust course at any time. Sam's comments yielded the following prompt from our facilitator, Dr. LaKisha Odom, Scientific Program Director at FFAR:<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn8" id="fnref8">[8]</a></sup> "Could GOAT develop a technological assessment framework to help developers consider the impacts of their technologies on nature?"</p><p>The response that stood out to me most came from Genna Fudin, an OpenTEAM Fellow working with Quivira Coalition and Point Blue Conservation Science.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn9" id="fnref9">[9]</a></sup> She proposed that technology should seek to expand access to nature and never restrict it. That did not mean access solely for the individual user, or even all humanity, but for every living thing on the planet. Her remarks struck me like a bolt, catalyzing an array of ideas that had been swimming around my head over the last three days, finally snapping them into place. I struggled to articulate it, so I asked to read aloud some antiquated English folk poetry, which I'd been mulling over earlier in the week.</p><blockquote><p>The law locks up the man or woman<br> Who steals the goose from off the common<br> But leaves the greater villain loose<br> Who steals the common from off the goose.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn10" id="fnref10">[10]</a></sup></p></blockquote><p>I'd first heard these anonymous lines in an interview with historian Peter Linebaugh, commemorating the 800th anniversary of <em>Magna Carta</em>.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn11" id="fnref11">[11]</a></sup> He was discussing its lesser known companion, the <em>Charter of the Forest</em>, which protected the peasantry's rights to forage and graze their animals on common lands. It was the first time I'd heard the longer history of the English commons, how it was enshrined in the English constitution and only phased out by a gradual process called enclosure that took centuries to complete. Enclosure is exactly what it sounds like: closing off common pasture or forest by means of fences, hedges or by blocking roads so that it's no longer accessible to the common peasantry. More recently I was reminded of the poem when Linebaugh recited it once again in an interview with David Bollier, a fact I would soon come to realize was no coincidence.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn12" id="fnref12">[12]</a></sup></p><p>Genna's comments fused together the final conceptual links between enclosure and the more erudite legal and socioeconomic theories I'd been reading about recently. There is a strain of communitarian thought, often associated with Murray Bookchin's theory of social ecology, that draws upon the legal principle of "usufruct" as an alternative to absolute property rights. It was a concept I was still struggling to grasp, particularly how the rights of usufruct were distinguished from real property rights (<em>jus in re propria</em>). How I understood it was that usufruct grants the rightsholder two distinct rights: first of all, the free <em>use</em> of an asset as they saw fit, and secondly, any profits or other material gains that may arise from it, the so-called "fruits" of the asset. These are termed <em>usus</em> and <em>fructus</em> in civil law, respectively, hence <em>usufruct</em>. Real property ownership grants all of that plus the right to the disposal (<em>abusus</em>) of the asset. That can include consuming, selling, irrevocably altering or destroying it.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn13" id="fnref13">[13]</a></sup></p><p>What I struggled with most was this: If someone is entitled to use an asset and its produce however one saw fit, how did that differ substantially from the right to sell or consume it? Weren't those just other ways to use it? It seemed redundant. Perhaps <em>abusus</em> meant the right to "transfer" the other two rights, <em>ususus</em> and <em>fructus</em>, or to otherwise fundamentally alter their terms — was that it? If so, it seemed an unnecessarily roundabout way to formulate it. Was it then some kind of "meta-right," if the right to the asset was not held directly but instead merely the right <em>to the rights</em> to the asset? That made even less sense.</p><p>Now when I thought about it in the light of universal access to nature, I remembered the other term for this third right: <em>alienation</em>. In a strictly legal sense, to alienate an asset carries little further significance than to "dispose of" it. In a sociological context, however, or merely in plain parlance, alienation carries a deeply psychological quality. That sense seems all the more acute when the thing you are alienating is nature itself, even if just a part of it. There is reciprocity between us and nature, a two-way subjectivity that transcends the mere owner/asset duality. I belong to nature as much as (or even more than) nature belongs to me, and to sever that tie would constitute a terrible injury. A free-market economy, however, requires that elements of nature be made fungible and comply with the rules of commodity exchange. To enclose nature, therefore, means to fundamentally <em>set it apart</em>. Nature becomes an asset or commodity. It is demoted to an insensible object and is no longer an equal or true subject. Meanwhile, anyone tied to that chunk of nature is in essence commodified too. It is a process that cuts both ways, alienating one from the other. This was certainly the experience of English peasants who were driven off the commons by enclosure. They were forced to move to urban centers and sell their labor for a wage in the emerging industrial economy. So not only was the <em>ecological value</em> of the land commodified and sold, but the very <em>social value</em> of the peasantry was itself made into a commodity, measured out by the punch clock, and made divisible as wage shares. Wherever the commons was enclosed, the commoners were duly confined, if not to the factory yard then invariably to the prison yard.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn14" id="fnref14">[14]</a></sup></p><h2 id="and-geese-will-still-a-common-lack" tabindex="-1">And Geese Will Still a Common Lack... <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#and-geese-will-still-a-common-lack" aria-label="Permalink to &quot;And Geese Will Still a Common Lack...&quot;">​</a></h2><p>While the plight of peasants hundreds of years in the past may seem remote to our modern sensibilities, I think we can still empathize with their position when we consider how the enclosure of digital spaces has been used to alienate us from our social relations and the natural world. The natural world is not limited to the merely physical, but includes things like knowledge, cultural practices, mental abstractions, and emotional affect states. When these parts of nature are enclosed by Big Data corporations or the aptly named "walled gardens" of social media conglomerates, we feel alienated. This alienation, at least according to one interpretation, can be attributed to the mechanism James Muldoon calls <em>data commodity fetishism</em>, defining it as "the perception of certain digital relationships between people [...] as having their value based not on the social relationships themselves but on the data they produce."<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn15" id="fnref15">[15]</a></sup> But it goes further than that. Digital enclosures certainly alienate us from our social relations, but that is just one aspect of the larger process of our alienation from the natural world as a whole.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn16" id="fnref16">[16]</a></sup> This extension of data commodification, as applied to nature, could not be more relevant to agriculture and technology. It gets to the heart of what I think Genna meant when she suggested farming technology should not restrict "access to nature."</p><p>The enclosure of the commons in centuries past was made legal by acts of Parliament, but it could not have been fully accomplished without physical deterrents. State-sanctioned violence, seldom spared, may have represented the bloodiest end of that spectrum, but its most visible and pervasive manifestation lay in the hedgerows that hemmed in the former commons. Many of those hedgerows even persist to this day, emblematic of the English countryside and the imagined idylls of yesteryear. In their own time, however, they were at once a symbol of class hierarchy and a physical line of defense. They formed a very real and necessary barrier, keeping the commoners off their erstwhile commons, thereafter the exclusive property of a rising class of wool barons. Hedgerows represented the alienation of common people from their land, from their social relations, and from their traditional ways of farming and husbandry. Intellectual property, or IP, is essentially a legal mechanism for enclosing knowledge today, analogous to the enclosure acts of the 18th century. Since the 1990s, these enclosures have rapidly extended their lawful reach through the corresponding expansion of copyright and patent protections. But the most effective means of enclosing knowledge in our time, I would argue, is to consolidate it in vast data centers and server farms owned by just a few tech monopolies. Property rights can be legislated and service contracts agreed to, but their final implementation is only achieved in these physical constructs. Digital enclosure comprises all the silicon, cables, metal, and concrete of those facilities, just as much as the abstract services and data they carry. Only then can access be effectively commodified in the form of subscriptions or advertising fees. The IP owner retains maximum control, with the ability to revoke access or modify the terms of service at any time, often outpacing legal authority to do so. This practice goes by many names. The industry jargon is Software-as-a-Service, or SaaS, while it is marketed to lay users in more poetic terms: <em>the cloud</em>. Opponents of cloud computing and proprietary software have quipped that this is just a euphemism for "someone else's computer." I propose that — trading one grandiose metaphor for another — we instead rebrand the cloud as the modern form of enclosure it truly is: <em>hedgerows in the sky</em>.</p><p>The hedgerows that enclosed the English commons of the 16th through 18th centuries did not go unopposed but were actively resisted over many generations. The Levellers were among the earliest dissidents for whom any records survive. They earned that name during the Midland Revolt of 1607 by "leveling" hedgerows in protest. Though some were drawn and quartered for their actions, they were never entirely suppressed. Some 40 years later, they were revived as the True Levellers, or Diggers, led by Gerrard Winstanley to establish a commune on St. George's Hill in the waning years of the English Revolution. Winstanley's pamphlets and tales of the Diggers would in turn serve as inspiration to social movements for centuries to come. The anonymous bard I quoted above, whoever they might have been, surely knew something of this struggle, and perhaps even participated in it. Therefore, it's not hard to hear both a warning and a call-to-arms in their final stanza:</p><blockquote><p>The law locks up the man or woman<br> Who steals the goose from off the common<br> And geese will still a common lack<br> Till they go and steal it back.</p></blockquote><p>If we were to heed their call, how would we begin leveling today's hedgerows?</p><h2 id="from-rhinebeck-to-durham" tabindex="-1">From Rhinebeck to Durham <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#from-rhinebeck-to-durham" aria-label="Permalink to &quot;From Rhinebeck to Durham&quot;">​</a></h2><p>I was a bit surprised to realize my ignorance of the parallels between modern software commons and premodern agricultural commons, but after speaking to others at GOAT, it became clear I was not alone. This was doubly true with the concept of enclosure. What was especially embarrassing to me was how many of us had carved out niche careers straddling both open technology and small-scale agriculture, spanning decades in some cases, yet few of us had more than a cursory knowledge of the history of the commons predating the Information Age.</p><p>The metaphor of "the commons" has become so pervasive in technology today. The first time I recall encountering it was from the Free Culture Movement of the early and mid-2000's. Its most prominent manifestation came in the form of Creative Commons, but the commons had also become a familiar means of characterizing crowd-sourced projects like Wikipedia, Flickr and the World Wide Web itself. The Free Culture Movement first gained momentum in the wake of the US Copyright Term Extension Act (aka, the Sonny Bono Act) and Digital Millennium Copyright Act (DMCA), both enacted in 1998. These drew immediate outcry from a clique of law professors at Duke and Harvard Universities, who specialized in intellectual property. The outcry became more public and vociferous when the DMCA was used first to pull the plug on Napster in 2001. The furor rose further as Napster's file-sharing successors fell one by one in a decade-long game of whack-a-mole with the RIAA and MPAA, the deep-pocketed trade associations and main litigants for the major music labels and film studios, respectively. This was the heyday of the Free Culture Movement.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn17" id="fnref17">[17]</a></sup> Its unofficial motto, "Information wants to be free," resonated with anyone who got a cease-and-desist letter from their Internet provider (myself included) or who merely saw the futility of police raids on sites like The Pirate Bay, when they'd just be back up and running within a day or two.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn18" id="fnref18">[18]</a></sup></p><p>Among the Free Culture Movement's coterie of legal scholars, Lawrence Lessig and Yochai Benkler were arguably its most visible champions, both hailing from Harvard's Berkman Klein Center for Internet &amp; Society. In the first few years their reputations stemmed primarily from the numerous amicus briefs they filed in support of defendants in copyright infringement cases. Later on, their published books and several widely viewed TED Talks extended their reach to a larger audience. For a few short years, concepts like "remix culture" and "network neutrality" enjoyed a glimmer of popular recognition. In the first decade of the new millennium, their work certainly raised public awareness of "the commons" and why it was important. This was particularly true among the more technologically savvy, but not exclusively. On the other hand, it does not seem that enclosure enjoyed any wider awareness during that period, at least not commensurate with the commons. Speaking for myself, I remained oblivious to the term until I learned it from Linebaugh in 2015. That was a decade after Lessig co-founded Creative Commons and Benkler had popularized the notion of "commons-based peer production." For his part, Benkler put both the commons and enclosure front and center in his earliest essays on the topic, such as "The Commons As A Neglected Factor of Information Policy" and "Free as the Air to Common Use: First Amendment Constraints on Enclosure of the Public Domain," from 1998 and 1999, respectively. I haven't found anything more than passing references to enclosure in Lessig's works. Regardless, it didn't seem to make as many inroads with technologists the way the commons had.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn19" id="fnref19">[19]</a></sup></p><p>There were other figures, however, who I don't personally recall from the Free Culture Movement's highpoint of popularity, and who didn't receive as much limelight, but who nevertheless turned out to be consequential to the history of the knowledge commons. First was James Boyle, one of the Duke Law professors specializing in IP and building on the work of his colleagues at Duke, such as David Lange and Jerome Reichman. I don't believe I'd encountered Boyle's work until after GOAT 2022, when I went looking for a deeper understanding of how the language of the commons came to be embraced by free culture and open source advocates of the last two decades, while enclosure went comparatively ignored. As early as 1996, Boyle penned a pivotal work in the study of information commons, <em>Shamans, Software, and Spleens</em>, but it was a later title that jumped out to me from all the rest: "The Second Enclosure Movement and the Construction of the Public Domain." The paper began with the epigraph:</p><blockquote><p>The law locks up the man or woman [...]<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn10" id="fnref10:1">[10:1]</a></sup></p></blockquote><p>Now the pieces were starting to fall into place. I tracked the discourse of enclosure through Boyle's footnotes, where he acknowledges that "the analogy to the enclosure movement has been too succulent to resist," and proceeds to give a laundry list of names from that scholarly milieu who had used it too. Yochai Benkler was listed there, of course, along with a few more names I was hitherto unaware of, like Hannibal Travis, whose 1999 <em>Pirates of the Information Infrastructure</em> is the best combined survey of the pre-industrial enclosure movement together with this "second enclosure movement," as Boyle calls it.</p><p>Boyle also names the aforementioned David Bollier, who would eventually reintroduce me to Peter Linebaugh's work, but who was also quite active in the early days of the "blogosphere" and advocating for Internet freedom. He was not an IP lawyer but rather a co-founder of the Public Knowledge and Commons Strategies Group. He continues that work at the Schumacher Center for New Economics where today he directs their Reinventing the Commons Program. In these roles, he has advanced a much broader vision for the commons, not just for information but for the commons in all its forms.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn20" id="fnref20">[20]</a></sup> Accompanying this, he has articulated a thorough critique of enclosure, in all its manifestations. A slightly different version of "stealing the commons from off the goose" shows up as the epigraph to Bollier's <em>Silent Theft: The Private Plunder of Our Common Wealth</em> in 2002, the same year Boyle published an early draft of his own essay featuring the poem. As it turns out, Peter Linebaugh also found it "too succulent to resist" and recycled it once more in the introduction to his 2014 book <em>Stop, Thief!</em><sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn21" id="fnref21">[21]</a></sup>.</p><p>Apart from being the object in this game of epigraphic hot potato, it's not surprising that the poem rose to the surface as a shared metaphor in such an atmosphere of cross-disciplinary collaboration. Looking at the participants list from the <em>Conference on the Public Domain</em> that was held at Duke Law School in 2001,<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn22" id="fnref22">[22]</a></sup> I can't help but speculate who might have first quoted the goose poem there, and how I may have unwittingly parodied that scene two decades later in Rhinebeck. Bollier or Boyle were both listed among the participants, but if it wasn't them there was no shortage of usual suspects. The list also include Elinor Ostrom, Charlotte Hess, Eben Moglen, John Perry Barlow, Yochai Benkler, "Larry Lessig," and even Mark Hosler of the band Negativland, who facilitated a round-table discussion titled "Art Crime / Crime Art." Yet I doubt it was either Benkler or Lessig who first brought the goose poem to the others' attention.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn23" id="fnref23">[23]</a></sup> In those heady post-Cold War days, even liberals like Lessig and Benkler took Francis Fukuyama's "end of history" as practically axiomatic, at least in any <em>serious</em> political discourse. With its distinctly revolutionary tone and the memory of bourgeois enclosures it chronicled, I suspect the poem may have seemed either too radical or too ridiculous to many in attendance. In any event, the more celebrated proponents of free culture seem to have shied away from the metaphors of enclosure, let alone any notion of the commons as <em>actual communal land tenure</em>. Enclosure never gained a foothold in the popular imagination like the commons did at the height of the Free Culture Movement, no matter how "irresistibly succulent" it may have first appeared.</p><p>As Bollier points out in <em>Silent Theft</em>, by omitting enclosure from the metaphor of the commons, the adversarial role of markets is conveniently ignored:</p><blockquote><p>It is important to speak of market enclosure because it reframes the economic narrative of the market. What the market considers incidental externalities (toxic waste, species extinction, safety hazards), the narrative of the commons regards as an assault on the community. Marketeers presume an entitlement to privatize clean air and water, public spaces, and even shared images and words.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn24" id="fnref24">[24]</a></sup></p></blockquote><p>I would go even further to say that this subtle omission obscures the tangible character of the commons and, with it, the acts of violence and sheer <em>physical force</em> that is required to enclose it. Skipping over that transgenerational struggle not only does an injustice to those who fought and died for the commons, but also limits our imaginations for what is possible in our own time.</p><p>I want to be clear that neither Benkler nor Lessig were arguing that these physical aspects did not matter. In <em>The Wealth of Networks</em>, Benkler provides a truly insightful table that breaks down different forms of enclosure in terms of its physical, logical, and content layers, explicitly borrowing from the OSI Model for computer networks. And it was Lessig's arguments for the end-to-end architecture of the Internet, in both physical and logical terms, which first led me to Boyle's essay on enclosure.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn25" id="fnref25">[25]</a></sup></p><h2 id="free-as-the-air-to-common-use" tabindex="-1">Free as the Air to Common Use <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#free-as-the-air-to-common-use" aria-label="Permalink to &quot;Free as the Air to Common Use&quot;">​</a></h2><p>Nevertheless, today's advocates for free culture and open source software are still mostly concerned with commoning what is abstract and ephemeral, though there are significant exceptions I will address later on. This is best summed up in another favorite quote of that era, from none other than Supreme Court Justice Louis Brandeis:</p><blockquote><p>The general rule of law is, that the noblest of human productions — knowledge, truths ascertained, conceptions, and ideas — become, after voluntary communication to others, free as the air to common use.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn26" id="fnref26">[26]</a></sup></p></blockquote><p>It forms the titular reference in a seminal paper from Benkler,<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn27" id="fnref27">[27]</a></sup> which is in turn cited by Boyle's "The Second Enclosure Movement" and elsewhere. Again, I don't mean to imply that it was their intent to privilege more substantial forms of property over the airy ones like information and molecular oxygen. But that's clearly the attitude that open source advocates took away from these statements.</p><p>The hardware and infrastructure required to store, process and move information around are treated as mere accidents or technical details. If they're considered at all they're taken as inconveniences to be worked around in policy, possibly subsidized, but never as substantive elements of the knowledge commons in their own right. Information acquires a supernatural character in this formulation. It is beyond the encumbrances of the physical world. Even the Swedish police who raided The Pirate Bay in 2006 had to concede that there were limits to what could be done to physically impede the flow of information. Information, after all, wants to be free.</p><p>Stewart Brand is often cited as the originator of this maxim, that "information wants to be free." He is the hub connecting two spokes of the baby boomers' cultural history: first their quest in the 1960s and 70s to discover new forms of consciousness through autonomous communities, then their seemingly disparate pursuit of free markets and tech-infused neoliberalism that climaxed in the 1990s and 2000s. Fred Turner connects all these dots in his <em>Counterculture to Cyberculture</em>. He makes a compelling argument that while the 60s counterculture can be viewed as a hotbed of radical politics (e.g., the Students for a Democratic Society (SDS) and the New Left), it also produced a deeply apolitical tendency that he dubs the New Communalism. Rather than seeking to change society for the better, New Communalists sought to drop out of civilization entirely. They forsook the comforts of their middle class, suburban upbringings, seeking to build whole new communities out on America's rural hinterlands. It would be a fresh new start for society, a place to take refuge while the old society sank beneath the tide. Required reading for many of these "back to the land" communards was <em>The Whole Earch Catalog</em>, which Stewart Brand edited and published. The communes seldom lasted more than a year or two, but their utopian dream of intentional communities persisted into the 1980s, when it re-emerged in the guise of the earliest <em>virtual</em> communities. It was in 1985 that Brand, once counted among Ken Kesey's Merry Pranksters, co-founded one of the earliest Internet startups called The WELL, together with some former members of a Tennessee commune known only as The Farm. Similar to its forerunner, Usenet, The WELL was a simple online bulletin board system, or what was commonly referred to as a BBS. It incubated a number of virtual communities that would eventually give rise to the Electronic Frontier Foundation, <em>Wired</em> magazine, Craigslist, and Salon.com, just to name a few. The utopian dream had become a reality, albeit virtual. Their success entrenched a growing sense of technological determinism. When that tech-positive optimism was combined with the laissez faire spirit of the post-history 1990s, it gave rise to a new brand of techno-libertarianism, which was a hallmark of the first dotcom boom and still prevails in Silicon Valley today. As is quite clear to many of us now, however, this optimism was misplaced. Problems like economic scarcity and social stratification don't just vanish with one wave of the magic wand of virtualization, as Turner warns:</p><blockquote><p>The rhetoric of peer-to-peer informationalism, however, much like the rhetoric of consciousness out of which it grew, actively obscures the material and technical infrastructures on which both the Internet and the lives of the digital generation depend. Behind the fantasy of unimpeded information flow lies the reality of millions of plastic keyboards, silicon wafers, glass-faced monitors, and endless miles of cable. All of these technologies depend on manual laborers, first to build them and later to tear them apart. This work remains extraordinarily dangerous, first to those who handle the toxic chemicals required in manufacture and later to those who live on the land, drink the water, and breathe the air into which those chemicals eventually leak.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn28" id="fnref28">[28]</a></sup></p></blockquote><p>The cost of disregarding information's earthly trappings is further borne out today by the way private streaming platforms have nonetheless managed to enclose the knowledge commons, quite thoroughly and in relatively short time. Jump ahead twenty years from when it seemed like Napster and torrenting would spell the death of copyright, we see subscription rates for platforms such as Netflix steadily rising every year, while fewer titles are available outside premium plans and mid-roll ads become longer and more frequent. This is how today's big platforms rake in more revenue than the premium cable channels of yesteryear ever dreamed was possible. It's also how our common cultural heritage continues to be enclosed. The DMCA, takedown notices and high profile raids played their role in all this, of course, but the commons was not lost due to licensing and regulation alone. In many ways it was precisely because the call for a knowledge commons stopped there. Beyond the fiber lines and standards like TCP/IP, it fell short of demanding any kind of public infrastructure that might have held such enclosures in check. Even the FCC's classification of Internet service providers (ISPs) as "common carriers," thereby subject to net neutrality regulation, has been stripped away in the last decade. Meanwhile, physical servers, databases, and most of all the considerable administration required to maintain those systems have largely been taken for granted, almost as a fact of nature.</p><h2 id="from-uttar-pradesh-to-seattle" tabindex="-1">From Uttar Pradesh to Seattle <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#from-uttar-pradesh-to-seattle" aria-label="Permalink to &quot;From Uttar Pradesh to Seattle&quot;">​</a></h2><p>Designating something <em>a fact of nature</em> may just as readily cast disdain as demonstrate reverence. There is no paradox or dialectic at play here, just a double standard, which is precisely why it has been a favorite rhetorical device of colonialist projects throughout history. The weaponization of nature in this way, with dire consequences for property rights, technology, land use, and agriculture, has been established most conclusively in the writing and activism of Dr. Vandana Shiva.</p><p>Nearly a decade before Benkler, Boyle and Bollier drew the comparison between copyright expansion and enclosure — reacting as they were to the passage of the DMCA and Sonny Bono Act of 1998 — Shiva cited the history of enclosure in response to an even more sweeping expansion of IP rights. Between 1989 and 1993, a whole suite of international laws, treaties, and free trade agreements were negotiated that would expand IP rights across borders and around the world. This was the legal and financial framework that created the World Trade Organization (WTO), heralding a new era of globalization and unfettered neoliberalism. Shiva represented the Research Foundation for Science, Technology &amp; Ecology (RFSTE), an organization comprised of scientists, conservationists, feminists, and peasant farmers from Uttar Pradesh, India. They resolutely opposed the environmental degradation and capitalist appropriation the WTO was poised to accelerate, as the effects were already apparent in their cities and villages. Among the agreements was a treaty obligation to uphold IP rights granted by other signatory nations. This was of particular concern to Shiva because chemical companies were seeking patents that would privatize the genotypes of plants that Indian farmers had previously bred and cultivated.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn29" id="fnref29">[29]</a></sup></p><p>The threat was first revealed in the case of neem, a plant endemic to Southeast Asia. The neem seed produces an oil that can be used as a natural and highly effective insect repellent, potentially replacing synthetic pesticides. Having already wreaked ecological havoc upon India, from the Bhopal Disaster to pesticide-resistant bollworms, U.S. chemical companies now wanted to patent this plant-based alternative (with active support from the USDA, I might add). When W.R. Grace &amp; Co. applied, the European Patent Office was only too happy to oblige and upheld the corporation's claim to the innovation. Despite 2,000 years of independent seed development by Indian plant breeders, the U.S. conglomerate monopolized the right to sell it back to them like coals to Newcastle. In the process, Grace &amp; Co. would enjoy a hefty profit while offsetting any decline in revenue from the sale of chemical pesticides due to environmental regulations or competition from safer alternatives like neem. The patent was eventually revoked, but only after ten years of relentless legal battles and grassroots campaigning by Shiva and Navdanya, the successor organization to the RFSTE.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn30" id="fnref30">[30]</a></sup></p><p>Shiva did not mince words in her denunciation of this new form of enclosure and the global policy regime that protected it. In her 1997 book, <em>Biopiracy</em>, she decried the inherent hostility to life that hid behind globalization's facade of free trade, free enterprise, and free markets:</p><blockquote><p>The freedom that transnational corporations are claiming through intellectual property rights protection in the GATT agreement on Trade Related Intellectual Property Rights (TRIPs) is the freedom that European colonizers have claimed since 1492. Columbus set a precedent when he treated the license to conquer non-European peoples as a natural right of European men. The land titles issued by the pope through European kings and queens were the first patents. The colonizer's freedom was built on the slavery and subjugation of the people with original rights to the land. This violent takeover was rendered "natural" by defining the colonized people as nature, thus denying them their humanity and freedom.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn31" id="fnref31">[31]</a></sup></p></blockquote><p>I draw attention to this episode and Shiva's analysis for several reasons. It's an early instance of the enclosure metaphor being applied to IP rights; that much is clear:</p><blockquote><p>Patents on life enclose the creativity inherent to living systems that reproduce and multiply in self-organized freedom. They enclose the interior spaces of the bodies of women, plants, and animals. They also enclose the free spaces of intellectual creativity by transforming publicly generated knowledge into private property. Intellectual property rights on life-forms are supposed to reward and stimulate creativity. Their impact is actually the opposite — to stifle the creativity intrinsic to life-forms and the social production of knowledge.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn32" id="fnref32">[32]</a></sup></p></blockquote><p>The fact that this enclosure lies at the intersection of agriculture and technology, settler colonialism and IP rights should also banish any residual notion that small-scale farming and open source software are unrelated concerns. The ideological connection between food sovereignty and technology sovereignty turns out to be nothing new. We may be just now rediscovering that here in America's coastal cities, but in some parts of the world, and perhaps in farming communities not so far from our urban centers, that understanding was never lost.</p><p>The precise framing of her analysis, however, carries an insight far more profound, far more <em>ontological</em> in character, than anything subsequent commentators on free culture were ready to claim. Shiva certainly acknowledges the value of the natural world and humanity's ties to it, but she also highlights Western colonialist forces have appealed to nature as the authority granting them to right to dispossess indigenous peoples of their land and resources all across the globe. This "conquest by naturalization," as she calls it, can be observed as far back as the Papal Bulls of Donation in 1493. To settle colonial disputes between the Catholic Monarchs of Spain and the King of Portugal, Pope Alexander VI drew a longitudinal line running down the middle of the Atlantic Ocean, just slicing off the Nordeste region of modern-day Brasil. He then "donated" all non-christian peoples and their lands on the left and right sides of that line to Spain and Portugal, respectively. The papal bulls, the treaties later negotiated between European courts, and the charters they granted to private joint stock companies were all the direct predecessors to the patents and other IP rights recognized by GATT and TRIPs, as Shiva points out.</p><p>The contempt European colonialists held for non-christian and indigenous peoples is abhorrent enough, but Shiva's analysis delves even deeper still. She examines the metaphysical assumptions, held both then and now, which underpin the moral arguments used to justify such wide-scale dehumanization. Not only were the people of the Americas, Africa, Asia, and Oceania relegated to mere <em>things of nature</em>, but nature itself was demoted to an unensouled object, to be set apart from and dominated by Christ-fearing white men.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn33" id="fnref33">[33]</a></sup></p><p>To an extent, this Cartesian dualism was quite rigid, with the dividing line between subject and object hewn razor-thin, but that is not to say it was immovable. Just like the lines of longitude demarcating colonial holdings were redrawn over time, from the Bulls of Donation in 1493 to the Treaty of Zaragoza in 1529, the bounds of what can be deemed insensate nature have shifted ever since. Today those lines are being redrawn to encompass knowledge and the code of life itself:</p><blockquote><p>The assumption of empty lands, <em>terra nullius</em>, is now being expanded to "empty life," seeds and medicinal plants. The takeover of native resources during colonization was justified on the ground that indigenous people did not "improve" their land. [...] The same logic is now used to appropriate biodiversity from the original owners and innovators by defining their seeds, medicinal plants, and medical knowledge as nature, as nonscience, and treating the tools of genetic engineering as the yardstick of "improvement." Defining Christianity as the only religion, and all other beliefs and cosmologies as primitive, finds its parallel in defining commercialized Western science as the only science, and all other knowledge as primitive.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn34" id="fnref34">[34]</a></sup></p></blockquote><p>Compare this with James Muldoon, writing in 2022, starting from the very next line I cited above where he defines his concept of "data commodity fetishism:"</p><blockquote><p>When we understand data as a natural resource we mystify the true source of its value in the human activity required to produce it. [...] Data is often thought of as an unclaimed good ‘out there’ in a digital <em>terra nullius</em> – an empty space in which tech entrepreneurs can assert their rights over this seemingly free resource.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn35" id="fnref35">[35]</a></sup></p></blockquote><p>Shiva's and Muldoon's observations are divided by a quarter century of technological development, including the advent of "Big Data" and multibillion-user social media networks. They address disparate facets of IP rights, too, from biotech patents to data use agreements. Yet they both identify these as clear instances of enclosure. Muldoon again:</p><blockquote><p>There is a historical analogy between the early capitalist enclosure of the commons and the digital enclosure of the internet by venture capitalists. [...] In the case of the digital sphere, Facebook claims ownership over the data produced from the daily interactions of our social lives. This data, which is co-created by communities of individuals on the social network, becomes the exclusive property of Facebook to be analysed and sold as advertising commodities. Facebook takes unfair advantage of their position by capturing this resource from a digital commons. At the time of the digital enclosure, the loss of public goods that would occur was not immediately obvious. But as these networks have grown within a privatised system of commodification, the extent of the theft is becoming more apparent.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn36" id="fnref36">[36]</a></sup></p></blockquote><p>What brings these two perspectives into alignment is a willingness to critique the neoliberal assumptions underlying these two forms of capital accumulation. Shiva was a prominent anti-globalization activist. The history of this movement, sometimes called counter-globalization, was partially obscured after the 2001 attacks on the World Trade Center, despite being so recent, but for roughly a decade it was perhaps the largest worldwide movement on the left, filling the breach between the end of the Cold War and the beginning of the so-called "War on Terror." Shiva was in Seattle on November 30, 1999 when the movement ostensibly reached its high-water mark. It was certainly the largest upwelling of anticapitalist sentiment in the U.S. during that decade, the likes of which would not be seen again until Occupy Wall Street.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn29" id="fnref29:1">[29:1]</a></sup> Muldoon, for his part, is writing from a distinctly Marxian and autonomist perspective, informed by the several major financial crises that have taken place since then, as well as the Occupy and Black Lives Matter movements. He argues to revive the principles of guild socialism, as formulated by G.D.H. Cole roughly a century ago, and apply them to modern technology in what Muldoon calls <em>Platform Socialism</em>, which is also the title of his book.</p><p>For the 1999 Seattle WTO Protests, Shiva and the RFSTE were joined by a wide array of supporters for organic food, small farming, and peasant rights, all marching to halt the WTO Ministerial Conference. The diversity of agricultural concerns represented is noteworthy. U.S.-based groups like the Pure Food Campaign and Family Farm Defenders were mobilized against GMO foods while also championing small family farms from the Midwest and coastal exurban farming communities. La Via Campesina was also there in force, demanding equitable land distribution, fairer wages, and safe working conditions. They were joined by other groups from the Global South, like the Food and Allied Workers Union of South Africa, and a few from the American South, like the Black Farmers and Agriculturalists Association.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn37" id="fnref37">[37]</a></sup> These last three groups were far more concerned with issues of social justice, rather than the previous groups' interests in consumer protections and agrarianism. Nevertheless, they presented a united front against the powers of global capital and trade. Shiva herself was uniquely poised to represent a broad spectrum of those interests, as she did the night after the first day of protests in a packed Seattle Town Hall. She sat shoulder-to-shoulder with Ralph Nader as they debated against David Aaron, then White House Under-Secretary of Commerce, and Scott Miller, Director of Global Policy for Procter and Gamble. The event reached a national audience by means of a live broadcast on C-SPAN, re-aired periodically over the following days. This is where many organic food advocates in the U.S. were first introduced to Shiva's work, as she fired a cascade of withering rebukes at these grandees of government and industry, all to thunderous applause.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn38" id="fnref38">[38]</a></sup></p><h2 id="open-source-meets-open-publishing" tabindex="-1">Open Source Meets Open Publishing <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#open-source-meets-open-publishing" aria-label="Permalink to &quot;Open Source Meets Open Publishing&quot;">​</a></h2><p>The 1999 Seattle WTO Protests also stand as a critical inflection point where the interests and organizing base of farming and technology activists momentarily fused into a single, coherent political force that acted decidedly against further enclosure of the global commons. While Shiva and Nader were setting up at Seattle Town Hall, a group of independent journalists, media activists, hackers, and free speech advocates were setting up shop as the Independent Media Center (IMC) in a donated storefront at 1415 3rd Avenue.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn39" id="fnref39">[39]</a></sup> On the web, they made their home at indymedia.org. While news coverage coming from major U.S. newsrooms was either non-existent or heavily biased against the protesters, the IMC was critical in disseminating reports of what was actually taking place. They shed light on the very real concerns shared by this diverse coalition of environmentalists, trade unionists, and civil liberty activists, presenting them as the working class people they really were, rather than the rioters and provocateurs portrayed in 5-second clips that aired on the nightly news. IMC had an unmatched vanage point. Tear gas seeped into their ground level offices during the most intense street battles, and at one point armoured police pounded on their door, demanding (without warrant) that IMC hand over the demonstrators who took refuge inside.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn40" id="fnref40">[40]</a></sup> As a result, indymedia.org received more web traffic than cnn.com at its peak, with 1.5 million unique visitors in its first week.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn41" id="fnref41">[41]</a></sup> The legacy of the IMC would live on in the influence it had on the digital media tactics of later movements, and the IMC itself would continue as an activist hub in Seattle for several years. Arguably its most lasting influence, however, was in the establishment of sister IMCs in cities and regions around the world. This was the birth of the Indymedia network, which at its peak in 2010 comprised as many as 175 centers.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn42" id="fnref42">[42]</a></sup> They shared some common open source publishing tools and many locales were provided with subdomains, such as barcelona.indymedia.org, but otherwise they were largely autonomous projects run by local activists in those regions.</p><p>Indymedia was not principally concerned with open source or free culture issues, but a few of the individual IMCs offered a glimpse of how the cross-pollination of free software and food sovereignty could yield unique outcomes. In 2005, software developers affiliated with the Portland IMC, the People's Food Co-op of Portland, and The Wedge Co-Op in Minneapolis released the open source code for a point-of-sale system dubbed Information Systems 4 Co-ops, or IS4C. As the Portland IMC reported at the time:</p><blockquote><p>This past Saturday morning, a group of co-op geeks gathered at People's Food Co-op and successfully ran IS4C on a Linux box running Ubuntu using MySQL 5 and PHP 5. Stop the presses. History has been made.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn43" id="fnref43">[43]</a></sup></p></blockquote><p>A fork of IS4C is still actively maintained to this day as CORE-POS, stewarded by the Tech Support Cooperative.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn44" id="fnref44">[44]</a></sup></p><h2 id="from-davos-to-the-lacandon-jungle" tabindex="-1">From Davos to the Lacandon Jungle <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#from-davos-to-the-lacandon-jungle" aria-label="Permalink to &quot;From Davos to the Lacandon Jungle&quot;">​</a></h2><p>Apart from forging more diverse alliances, Indymedia also represents an <em>ideological</em> alternative to the centrist political leanings of free culture, open source, and online privacy movements. April Glaser, writing for <em>Logic(s)</em> magazine in 2019, places Indymedia and its legacy in stark contrast to advocacy groups like the Electronic Frontier Foundation (EFF), co-founded by John Perry Barlow, a former Grateful Dead lyricist and later denizen of The WELL, who would also be in attendence for the 2001 <em>Conference on the Public Domain</em> alongside Lessig and Benkler.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn22" id="fnref22:1">[22:1]</a></sup> Glaser points out how in the same year that Barlow penned his techno-libertarian manifesto, <em>A Declaration of the Independence of Cyberspace</em>, a very different vision for cyberspace would emerge from far more revolutionary environs. <sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn45" id="fnref45">[45]</a></sup> This declaration would come straight from the balaclava- encircled mouth of Subcommandante Marcos, spokesperson for the Zapatista Army of National Liberation (EZLN).<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn46" id="fnref46">[46]</a></sup></p><p>The political climate — to say nothing of the literal climate — surrounding these two manifestos could not have been more dissimilar. Barlow signed his declaration from Davos in the Swiss Alps on February 8, 1996, having ostensibly found inspiration in the World Economic Forum, which he attended two days before. Delivered a few months later on August 3, 1996, the <em>Second Declaration of La Realidad</em> was Marcos' valediction to the delegates from over 40 countries, plus anywhere from 3 to 5 thousand other activists, journalists, and intellectuals, who all journeyed to Chiapas, Mexico for the <em>First Intercontinental Gathering for Humanity and Against Neoliberalism</em>. This 5-day <em>encuentro</em>, or gathering, was held deep in the Lacandon Jungle near the Guatemalan border. Many of the sessions took place in open-air clearings, tents, and lean-tos. There would be another intercontinental <em>encuentro</em> the following year in Spain, plus a few smaller, intra-continental gatherings across Europe and North America. Eventually, these <em>encuentros</em> would inspire the World Social Forum, named in conscious opposition to the World Economic Forum in Davos. The first WSF was held in Brazil in 2001, attended by many of the same participants from the first <em>encuentro</em> in 1996 and borrowing many of its methods.</p><p>On the final day of that first <em>encuentro</em>, however, Marcos called for "a collective network" of resistance against neoliberalism, using the nascent World Wide Web to link activists from all over the world. The EZLN had already shown itself so adept at mobilizing international support through the online publishing. Communiques such as the <em>Second Declaration of La Realidad</em> had been published online since the uprising began in 1994.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn47" id="fnref47">[47]</a></sup> Glaser observes how "the organizers who went on to build Indymedia heard this call," some three years prior to the Battle of Seattle. She continues:</p><blockquote><p>The Indymedia organizers would be the children of Marcos, not Barlow. While the two philosophies had points of contact, they came from different places of concern. Indymedia activists would agree with the techno-libertarians that politicians and police couldn’t be trusted in their networks. But they didn’t see cyberspace as an open frontier of <em>individuals unhindered by governments</em>. Rather, the activists saw cyberspace as a place for <em>communities</em>.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn46" id="fnref46:1">[46:1]</a></sup></p></blockquote><p>Techno-libertarians, then and now, claim to be building political power from the ground up, but it's for the sole benefit of isolated individuals. The complete atomization of society into self-interested agents is not the same as bottom-up organization. It's a lie that merely enables the top-down exploitation of the many by the few. Coincidentally, it is the same alienated condition that the thought leaders at Davos tend to mistake for "freedom."</p><p>The anti-globalization organizers, on the other hand, came from small, localized bases of power, but they also knew that no individual could seriously challenge the centralized power of global capital alone. Instead, they leveraged their collective agency and organized their communities. They unequivocally championed autonomy for individuals at all levels of society, but they would not sacrifice the autonomy of the <em>community</em> just to preserve some rarefied ideal of absolute individualism. The activists in Seattle, Chiapas, and Uttar Pradesh wanted something more than individual freedom; they sought <em>collective liberation</em>, and that meant defending whatever commons still remained, while restoring any that had already been enclosed.</p><h2 id="tierra-y-libertad" tabindex="-1">Tierra y Libertad <a class="header-anchor" href="https://www.runrig.org/posts/hedgerows.html#tierra-y-libertad" aria-label="Permalink to &quot;Tierra y Libertad&quot;">​</a></h2><p>Although the commons had become a byword for free culture and open source software by the early 2000s, it was a hollow shell of the more ambitious program for the commons that persisted in other times and places. Perhaps it is to be expected that Silicon Valley privacy advocates and East Coast legal scholars dialed back their rhetoric, at least in comparison to the more radical vision of the commons espoused by anti-imperialist thinkers at the time. By omitting enclosure and all its antagonisms, however, this anemic account of the commons lost all its countervailing force and dynamism. The new digital commons was static, politically neutral, and devoid of material consequence. Immaterial as it was, it acquiesced so easily to the prevailing neoliberal order, essentially just another "free gift of nature," as Adam Smith might have called it.</p><p>There was surely no want of critical discourse on the commons in other fields at this time. One only needs to look at how Elinor Ostrom rose to prominence in those same years, beginning with her highly praised <em>Governing the Commons</em> in 1990, and culminating with the 2009 Nobel Prize in economics for her analysis of common-pool resources. In 2006 Silvia Federici's groundbreaking work, <em>Caliban and the Witch</em>, forever linked the history of the commons and enclosure to the Marxist feminist critiques of social reproduction and primitive accumulation. It should also come as no great shock that a wealth of contemporary literature on the commons emerged from the fields of social ecology and degrowth economics.</p><p>Conspicuously absent from this discourse, however, were the local food and organic farming movements that reached their zenith in the U.S. during this very same period. Although the free culture and open source movements' conception of the commons might have been some pretty weak tea, it was at least a vision. To find any mention of the commons or enclosure from self-proclaimed locavores of that time would have been a distinct challenge. There certainly wasn't anything like the rich historical commentaries or nuanced discourse that permeated the anti-globalization movement.</p><p>What's confounding about all of it is that the history of the commons is essentially an <em>agrarian history</em>, yet at the same moment when a revitalized image of agrarianism was emerging from the organics movement, it was the technologists, <em>not</em> the agriculturalists, who embraced the metaphor. It shouldn't be presumed that the proponents of organic food and agriculture lagged behind the technologists in political sensibility or acumen — far from it. Their political savvy and organizing ability is attested by the massive public awareness campaigns they launched<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn48" id="fnref48">[48]</a></sup> and significant legislative victories they achieved all throughout the 2000's<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn49" id="fnref49">[49]</a></sup>. It's debateable whether open source and free culture advocates could claim anything comparable in terms of legislation.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/hedgerows.html#fn50" id="fnref50">[50]</a></sup></p><p>This may be where the cognitive dissonance arises between these two seemingly sympathetic movements. In an era of tepid U.S. politics, predicated largely on consumer protection, both have been portrayed as more or less progressive movements. This broad assessment, however, smooths over their rugged political contours. Upon closer inspection, each was internally quite diverse, containing fractious constituencies who held disparate motivations that were sometimes directly opposed to one other. Situated amidst the broader context of contemporary geopolitics, it's even harder to ignore the diversity of ideology. For the technologists, we see this most evidently in the contrasts between Indymedia and the Electronic Frontier Foundation. If the organic and local food movements correspond to one of these two fronts, it's undoubtedly the techno-libertarianism side of the schism. Virginia farmer Joel Salatin, the self-described "Christian libertarian environmentalist capitalist" and darling of the local food world back then, makes an excellent stand-in for John Perry Barlow in this regard.</p><p>This still begs the question: was there a corresponding collectivist movement in food and agriculture during this period in the U.S., something analogous to Indymedia? And if so, where? I've given short shrift to the recent history of sustainable farming in this essay, and I will have to address those details in a subsequent essay, since this one is already three times the length I'd originally intended. For my own understanding, I needed to give a full account of these two movements before I could begin grappling with the more nuanced aspects of the commons and enclosure. Because I first encountered the commons through open source software, that's where it made the most sense to begin unravelling my own associations with the concept. The issue of the agricultural commons will have to wait. It also doesn't escape me that I've yet to rejoin my own earlier question, "How <em>do</em> we begin leveling today's hedgerows?" That, too, I leave to a separate piece.</p><p>At the moment, my personal exploration of the commons is situated within a certain community of practice, principally the Gathering for Open Agricultural Technology, but also Social.Coop and the Skywoman community. I think it's critical to acknowledge this, because my own understanding, and in fact the very content of this essay, has proceeded directly from the conversations I've shared with the people in those communities. Those conversations began long before the gathering in Rhinebeck in 2022, and have continued right up through the time of writing this. Whatever criticism I may have expressed regarding sustainable agriculture or open technology, they did ultimately bring me to this time and place where such a dialogue was possible. All navel-gazing aside, it's not lost on me that this environment, the set of social relations, professional ties, and the friendships of many years that comprise this network of practitioners, is just as much a part of the commons as anything that can be pushed to a public GitHub repository or licensed as free software under the GPL.</p><p>In the end, the substance of the commons — whether it is physical or abstract, rivalrous or non-rivalrous, information or land — plays far less a role in making it a commons than we might think. What matters more is the quality of our social bonds, how our obligations to each other also strengthen our commitment to preserve the commons. Enclosure, too, is more than just a simple barrier, boundary, or hedgerow: it is a severing of the ties that connect us to other people and to life more generally, while uprooting us from the land and our sense of place within it. The same is true with the enclosure of knowledge, which estranges us from the markers of culture and our shared ways of doing things.</p><p>The commons will emerge wherever we can come together as a whole and testify that, <em>Although we may use a thing, care for it, and maintain it, that does not give us sole dominion over it, nor over how others may wish to use and care for it</em>. Stated that way, the logic of the commons sounds like a bit of a platitude. So be it, but there's a subtle truth in the statement, something that first eluded me when I was struggling to make sense of such high and mighty concepts like <em>usufruct</em> and <em>alienation</em>. The commons is not ours to dispose of as we wish. We cannot alienate it from ourselves, nor us from it. We may partake of common land, its fruits, or the knowledge concerning it, but in the end we must all give back all that we take, returning it to the whole.</p><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p><a href="https://github.com/hometown-fork/hometown/wiki" target="_blank" rel="noreferrer">Hometown</a>, a fork of <a href="https://joinmastodon.org/" target="_blank" rel="noreferrer">Mastodon</a>, evolved from a private social media network called Friend Camp, started by Darius Kazemi "for about 50 of my friends" in 2018. The <a href="https://github.com/hometown-fork/hometown/wiki/Hometown-servers/72d3245d9416f544e26ec1300e904465263f2829" target="_blank" rel="noreferrer">project's wiki</a> lists 13 topic-based servers, 3 geographic community servers, and 7 general servers running Hometown, a modest but extremely dedicated base of users. Kazemi documents its origins in <a href="https://runyourown.social" target="_blank" rel="noreferrer">runyourown.social</a>, a guide for "How to run a small social network site for your friends." Mastodon itself stems from development of the <a href="https://dustycloud.org/blog/activitypub-is-a-w3c-recommendation/" target="_blank" rel="noreferrer">ActivityPub W3C Recommendation</a>. This standard allows Mastodon servers to connect or "federate" with one another, along with non-Mastodon servers like Pixelfed, PeerTube, or even Meta's Threads, so long as they also implement ActivityPub. I myself am one of a few thousand member-users on <a href="https://social.coop/about" target="_blank" rel="noreferrer">social.coop</a>, a cooperatively managed Mastodon instance. <a href="https://www.runrig.org/posts/hedgerows.html#fnref1" class="footnote-backref">↩︎</a></p></li><li id="fn2" class="footnote-item"><p>"Data sovereignty" is still a highly malleable term. There exist several distinct yet closely related definitions that can subtly shift the meaning from one context to the next. It seems the term was first picked up in the wake of Edward Snowden's revelations of the United States' PRISM spy program, a global surveillance network that flouted national borders as well as international law. In this early sense, data sovereignty pertained mainly to the sovereignty of nation-states to govern the data that resided within or was transported across their own territories. Around the same time, discussions among indigenous peoples from North America and Oceania began to connect their broader struggles for tribal and national sovereignty with this post-Snowden discourse, as well as the need to govern their own data. This yielded the principle known as Indigenous Data Sovereignty, or IDS. Particularly in the First Nations of North America, IDS became imbued with a sense of collective sovereignty that held precedence over individual sovereignty but still struck a fair balance between them. This is clearly expressed in a discussion paper from The First Nations Information Governance Centre (FNIGC) titled <a href="https://fnigc.ca/wp-content/uploads/2022/09/FNIGC_Discussion_Paper_IM_Regime_Data_Sovereignty_EN.pdf" target="_blank" rel="noreferrer">"Exploration of the Impact of Canada’s Information Management Regime on First Nations Data Sovereignty"</a>:</p><blockquote><p>While being cautious to respect diversity, there are some generalizations that can be made about common differences between First Nations perspectives and those of Canada. For example, many First Nations philosophies of interconnectedness explain their relationship to their lands, cultures, and each other, a relationship of belonging and responsibility that are different from the philosophy expressed by the Crown. The concept of what is considered private is an additional example. [...] While it is important that Canada respect First Nation individual’s privacy in their information management regime, it is equally important that Canada recognize First Nations collective rights to privacy and data sovereignty.</p></blockquote><p>This is in stark contrast to the purely Westphalian sense of sovereignty that prevailed among European privacy advocates in the mid-2010s. Whether by direct influence from IDS or by independent development, the European Commission began to broaden its own definition of "data sovereignty," as evidenced in this glossary entry from <a href="https://publications.jrc.ec.europa.eu/repository/handle/JRC129900" target="_blank" rel="noreferrer">a 2023 data policy paper</a>:</p><blockquote><p>Data sovereignty involves enhancing control by organisations and individuals over data that they contribute to generating. It implies participation in data governance and allows individuals and organisations to self-determine how, when and at what price others may use their data across the value chain. It means that data holders can safeguard user data, and ensure that it is used only in accordance with strictly defined rules.</p></blockquote><p>For a comprehensive meta-analysis of the term's usage in academic literature, see Hummel, P., Braun, M., Tretter, M., &amp; Dabrock, P. (2021). <a href="https://doi.org/10.1177/2053951720982012" target="_blank" rel="noreferrer">"Data Sovereignty: A review"</a>. Big Data &amp; Society, 8(1). <a href="https://www.runrig.org/posts/hedgerows.html#fnref2" class="footnote-backref">↩︎</a></p></li><li id="fn3" class="footnote-item"><p>Sci-Hub, Anna's Archive, and Library Genesis, are among the most prominent <a href="https://monoskop.org/Shadow_libraries" target="_blank" rel="noreferrer">shadow libraries</a> around today. <a href="https://www.runrig.org/posts/hedgerows.html#fnref3" class="footnote-backref">↩︎</a></p></li><li id="fn4" class="footnote-item"><p>In short, an <a href="https://web.archive.org/web/20191208123152/http://unconference.net/unconferencing-how-to-prepare-to-attend-an-unconference/" target="_blank" rel="noreferrer">unconference</a> is much like an industry conference, but instead of presentations, panels, and other prepared events, the participants collaboratively decide on the program on the first day. Facilitation is a shared task and the sessions are usually take the form of a seminar or round-table. <a href="https://www.runrig.org/posts/hedgerows.html#fnref4" class="footnote-backref">↩︎</a></p></li><li id="fn5" class="footnote-item"><p><a href="https://forum.goatech.org/t/session-J4N/1340" target="_blank" rel="noreferrer">"Session: Justice for Nature"</a>, forum.goatech.org. The notes and discussions for most of the sessions are mostly kept on the forum while the unconference is taking place, and then serve as an archive and a locus for follow-up conversations afterwards. <a href="https://www.runrig.org/posts/hedgerows.html#fnref5" class="footnote-backref">↩︎</a></p></li><li id="fn6" class="footnote-item"><p>The Cooperative for Ecological Proximity Agriculture, or <a href="https://cape.coop/" target="_blank" rel="noreferrer">CAPÉ</a> from the original French, <em>Coopérative pour l’agriculture de proximité. écologique</em>. <a href="https://www.runrig.org/posts/hedgerows.html#fnref6" class="footnote-backref">↩︎</a></p></li><li id="fn7" class="footnote-item"><p>Lindsay Ems, <a href="https://direct.mit.edu/books/oa-monograph/5347/Virtually-AmishPreserving-Community-at-the" target="_blank" rel="noreferrer"><em>Virtually Amish: Preserving Community at the Internet's Margins</em></a> Virtually Amish (Cambridge, Massachusetts: The MIT Press, 2022), 27-28, <a href="https://doi.org/10.7551/mitpress/11792.001.0001" target="_blank" rel="noreferrer">https://doi.org/10.7551/mitpress/11792.001.0001</a>. <a href="https://www.runrig.org/posts/hedgerows.html#fnref7" class="footnote-backref">↩︎</a></p></li><li id="fn8" class="footnote-item"><p><a href="https://foundationfar.org/about/people/lakisha-odom/" target="_blank" rel="noreferrer">Professional bio for LaKisha Odom, Ph.D.</a>, Scientific Program Director for Soil Health at the Foundation for Food and Agriculture Research (FFAR). <a href="https://www.runrig.org/posts/hedgerows.html#fnref8" class="footnote-backref">↩︎</a></p></li><li id="fn9" class="footnote-item"><p>Fudin, Genna. <a href="https://openteam.community/genna-fudin-openteam-fellow-shares-reflections-thus-far/" target="_blank" rel="noreferrer">"Genna Fudin, OpenTEAM Fellow, Shares Reflections Thus Far"</a>, OpenTEAM blog, 2023 Feb 23. <a href="https://www.runrig.org/posts/hedgerows.html#fnref9" class="footnote-backref">↩︎</a></p></li><li id="fn10" class="footnote-item"><p>I'll borrow straight from James Boyle here that "Apart from being anonymous, the poem is extremely hard to date." Boyle gives the most thorough account of its provenance that I have yet found. He concludes in the first footnote to <a href="https://scholarship.law.duke.edu/lcp/vol66/iss1/2/" target="_blank" rel="noreferrer">"The Second Enclosure Movement"</a>:</p><blockquote><p>The context makes it appear that the poem itself must date from the late 18th century. In other sources, the poem is sometimes dated at 1764 and said to be in response to Sir Charles Pratt’s fencing of common land.</p></blockquote><p>For the last claim he points to a rather obscure <a href="https://web.archive.org/web/20060718033403/https://www3.nd.edu/~histast4/exhibits/papers/Freiburger/index.html#Note15" target="_blank" rel="noreferrer">"poster paper" on land surveying</a> by independent researcher Dana A. Freiburger, who in turn cites T.H. Worth's <em>The Anstey Enclosures: a study of Anstey based on a close scrutiny of the 1761 Acts of Enclosure, and a lifetime spent in walking over the fields of Anstey</em>, self-published in 1978. Boyle cites a few other sources, but I myself have had no success tracking them down any further than the Freiburger paper. <a href="https://www.runrig.org/posts/hedgerows.html#fnref10" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/hedgerows.html#fnref10:1" class="footnote-backref">↩︎</a></p></li><li id="fn11" class="footnote-item"><p><em>The Laura Flanders Show</em>, <a href="https://www.youtube.com/watch?v=nSF3m_Uav6Y" target="_blank" rel="noreferrer">"Peter Linebaugh: Who Owns the Commons? An 800 Year Fight for Public Goods"</a>, 2015 Jan 6. <a href="https://www.runrig.org/posts/hedgerows.html#fnref11" class="footnote-backref">↩︎</a></p></li><li id="fn12" class="footnote-item"><p>David Bollier, <a href="https://www.bollier.org/blog/peter-linebaugh-what-history-commoning-reveals" target="_blank" rel="noreferrer">"Peter Linebaugh on What the History of Commoning Reveals"</a>, 2021 May 01. <a href="https://www.runrig.org/posts/hedgerows.html#fnref12" class="footnote-backref">↩︎</a></p></li><li id="fn13" class="footnote-item"><p>In civil or Roman law, the Latin terms would translate: <a href="https://www.lsd.law/define/jus-in-re-propria" target="_blank" rel="noreferrer"><em>jus in re propria</em></a>, "right to [one's] own thing"; <a href="https://www.lsd.law/define/jus-utendi" target="_blank" rel="noreferrer"><em>jus utendi</em></a>, "right to use" or literally "the using"; <a href="https://www.lsd.law/define/in-fructu" target="_blank" rel="noreferrer"><em>jus in fructu</em></a>, "right to the fruit [of a thing]"; <a href="https://www.lsd.law/define/jus-abutendi" target="_blank" rel="noreferrer"><em>jus abutendi</em></a>, "right to use up" as in "to expend." <a href="https://www.runrig.org/posts/hedgerows.html#fnref13" class="footnote-backref">↩︎</a></p></li><li id="fn14" class="footnote-item"><p>It cannot be overemphasized that this migration was anything but voluntary. Already faced with poverty and imminent starvation, landless peasants were further compelled into the cities and factories by a series of laws known as the Vagabonds Acts (later the Vagrancy Acts). These laws, passed in lockstep with enclosure between the 14th and 19th centuries, found persons guilty for the crime of "idleness" if they had no deed of property, no employer who would vouch for them, and if they could not present any other proof of lawful income. Their stipulated punishments ranged from imprisonment to whipping, branding, and even death for repeated offenses, though prison or execution sentences might be commuted if they agreed to a period of indentured servitude. As enforcement became increasingly difficult through the course of the Industrial Revolution, they were a significant factor contributing to the creation of modern police forces in England and elsewhere in Europe, wherever similar legislation prevailed. Marx provides a thorough but concise overview in Chapter 28 of <em>Capital Volume I</em>, 896-99. <a href="https://www.runrig.org/posts/hedgerows.html#fnref14" class="footnote-backref">↩︎</a></p></li><li id="fn15" class="footnote-item"><p><em>Platform Socialism</em> (Pluto Press, 2022), p. 18. Muldoon explicitly refers to the Marxian concept of commodity fetishism, and I am also drawing heavily on Marx's theory on the alienation (or estrangement) of labor. The <a href="https://www.marxists.org/archive/marx/works/1844/epm/index.htm" target="_blank" rel="noreferrer">"Economic &amp; Philosophic Manuscripts of 1844"</a> are especially ripe for application to today's forms of digital enclosure, and I hope to provide a more thorough exploration of those themes in a subsequent essay. <a href="https://www.runrig.org/posts/hedgerows.html#fnref15" class="footnote-backref">↩︎</a></p></li><li id="fn16" class="footnote-item"><p>Social ecologists like Murray Bookchin would contend, and I agree, that nature does indeed comprise both society and technology, though it may seem less and less a part of nature today. The introductory chapter, "The Concept of Social Ecology," in his classic <a href="https://theanarchistlibrary.org/library/murray-bookchin-the-ecology-of-freedom" target="_blank" rel="noreferrer"><em>Ecology of Freedom</em></a> provides a solid introduction to the idea that human nature and social relations are but mere aspects of nature in its entirety. He refers to the social part and the larger whole as second nature and first nature, respectively. Further analysis of how this extends to technology specifically can be found in Chapter 9 of the same, "Two Images of Technology." <a href="https://www.runrig.org/posts/hedgerows.html#fnref16" class="footnote-backref">↩︎</a></p></li><li id="fn17" class="footnote-item"><p>For a thorough telling of these legal battles, see the sections "The Digital Millennium Copyright Act of 1998" and "The Battle over Peer-to-Peer Networks" in Chapter 11 of Yochai Benkler's <em>The Wealth of Networks</em>, pp. 413-29. <a href="https://www.runrig.org/posts/hedgerows.html#fnref17" class="footnote-backref">↩︎</a></p></li><li id="fn18" class="footnote-item"><p>Bowman, John (9 June 2006), <a href="https://web.archive.org/web/20130910162506/http://www.cbc.ca/news/background/tech/piratebay.html" target="_blank" rel="noreferrer">"The Pirate Bay"</a>, <em>Canadian Broadcasting Corporation</em>. <a href="https://www.runrig.org/posts/hedgerows.html#fnref18" class="footnote-backref">↩︎</a></p></li><li id="fn19" class="footnote-item"><p>See the Benkler's <a href="https://benkler.org/Pub.html" target="_blank" rel="noreferrer">"Publications"</a> and Lessig's <a href="https://benkler.org/Pub.html" target="_blank" rel="noreferrer">"Published Writing"</a> for full bibliographies and links to their open access articles and books. <a href="https://www.runrig.org/posts/hedgerows.html#fnref19" class="footnote-backref">↩︎</a></p></li><li id="fn20" class="footnote-item"><p><a href="https://centerforneweconomics.org/people/david-bollier/" target="_blank" rel="noreferrer">Professional bio of David Bollier</a>, Reinventing the Commons Program Director at the Schumacher Center for New Economics. <a href="https://www.runrig.org/posts/hedgerows.html#fnref20" class="footnote-backref">↩︎</a></p></li><li id="fn21" class="footnote-item"><p>David Bollier, <a href="https://web.archive.org/web/20120226001742/http://www.silenttheft.com/intro.htm" target="_blank" rel="noreferrer"><em>Silent Theft: The Private Plunder of Our Common Wealth</em></a> (New York: Routledge, 2002), 14. David Bollier, <a href="https://www.bostonreview.net/forum/david-bollier-reclaiming-commons/" target="_blank" rel="noreferrer">"Reclaiming the Commons"</a><em>Boston Review</em>, 2002 Jun 01. Peter Linebaugh, <em>Stop, Thief! The Commons, Enclosures, and Resistance</em> (Oakland, California: PM Press, 2014), 12. <a href="https://www.runrig.org/posts/hedgerows.html#fnref21" class="footnote-backref">↩︎</a></p></li><li id="fn22" class="footnote-item"><p>The <a href="https://www.tech-insider.org/internet/research/2001/1109.html" target="_blank" rel="noreferrer"><em>Conference on the Public Domain</em></a>. <a href="https://www.runrig.org/posts/hedgerows.html#fnref22" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/hedgerows.html#fnref22:1" class="footnote-backref">↩︎</a></p></li><li id="fn23" class="footnote-item"><p>Nor do I suspect it was John Perry Barlow, but more on that later. <a href="https://www.runrig.org/posts/hedgerows.html#fnref23" class="footnote-backref">↩︎</a></p></li><li id="fn24" class="footnote-item"><p>Bollier, <em>Silent Theft</em> 49. <a href="https://www.runrig.org/posts/hedgerows.html#fnref24" class="footnote-backref">↩︎</a></p></li><li id="fn25" class="footnote-item"><p>Yochai Benkler, <a href="https://web.archive.org/web/20110525071000/http://www.jus.uio.no/sisu/the_wealth_of_networks.yochai_benkler/11.html#696" target="_blank" rel="noreferrer">"Table 11.1: Overview of the Institutional Ecology"</a> and <a href="https://web.archive.org/web/20110525071000/http://www.jus.uio.no/sisu/the_wealth_of_networks.yochai_benkler/11.html#_157" target="_blank" rel="noreferrer">Chapter 11, n. 4</a>, <em>The Wealth of Networks</em>, 2006, pp. 395, 488. Lawrence Lessig, <a href="https://scholarship.law.duke.edu/dlj/vol51/iss6/2/" target="_blank" rel="noreferrer">"The Architecture of Innovation"</a>, <em>Duke Law Journal</em>, Vol. 51:1783, 2002. <a href="https://www.runrig.org/posts/hedgerows.html#fnref25" class="footnote-backref">↩︎</a></p></li><li id="fn26" class="footnote-item"><p>Int’l News Serv. v. Associated Press, 248 U.S. 215, 250 (1918) (Brandeis, J., dissenting). <a href="https://www.runrig.org/posts/hedgerows.html#fnref26" class="footnote-backref">↩︎</a></p></li><li id="fn27" class="footnote-item"><p>Yochai Benkler, <a href="https://benklero.ipower.com/Free%20as%20the%20Air.pdf" target="_blank" rel="noreferrer">"Free as the Air to Common Use: First Amendment Constraints on Enclosure of the Public Domain"</a>, 74 N.Y.U. Law Review 354 (1999). <a href="https://www.runrig.org/posts/hedgerows.html#fnref27" class="footnote-backref">↩︎</a></p></li><li id="fn28" class="footnote-item"><p>Fred Turner, <em>From Counterculture to Cyberculture</em>, (Chicago and London: <em>The University of Chicago Press</em>, 2010), 260. <a href="https://www.runrig.org/posts/hedgerows.html#fnref28" class="footnote-backref">↩︎</a></p></li><li id="fn29" class="footnote-item"><p><em>Democracy Now!</em>, <a href="https://www.democracynow.org/2019/11/27/1999_wto_protests_20_years_later" target="_blank" rel="noreferrer">"20 Years After the Battle of Seattle: Vandana Shiva &amp; Lori Wallach on Historic 1999 WTO Protests"</a>, 2019 Nov 27. <a href="https://www.runrig.org/posts/hedgerows.html#fnref29" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/hedgerows.html#fnref29:1" class="footnote-backref">↩︎</a></p></li><li id="fn30" class="footnote-item"><p>Navdanya, <a href="https://navdanya.org/biopiracy-campaign-1" target="_blank" rel="noreferrer">"Biopiracy Campaign"</a>. See also <em>BBC News</em>, <a href="http://news.bbc.co.uk/1/hi/sci/tech/4333627.stm" target="_blank" rel="noreferrer">"India wins landmark patent battle"</a>, 2005. <a href="https://www.runrig.org/posts/hedgerows.html#fnref30" class="footnote-backref">↩︎</a></p></li><li id="fn31" class="footnote-item"><p>Vandana Shiva, <em>Biopiracy: the Plunder of Nature and Knowledge</em> (Boston, MA: South End Press, 1997), 2-3. <a href="https://www.runrig.org/posts/hedgerows.html#fnref31" class="footnote-backref">↩︎</a></p></li><li id="fn32" class="footnote-item"><p>Ibid., 7. <a href="https://www.runrig.org/posts/hedgerows.html#fnref32" class="footnote-backref">↩︎</a></p></li><li id="fn33" class="footnote-item"><p>Varying forms of moral dualism such as this have underpinned Western ethics and epistemology since at least the Enlightenment, but it is not particular to Christian theology or any other faith system for that matter. Known in antiquity as Manichaeism, today it is a common tendency among proponents of New Atheism as much as it is among Christian or Hindu nationalist sects. On the other hand, a more concordant view of Christian society's relationship to both nature and non-believers can be traced from the Brethren of the Free Spirit of the High Middle Ages through to Latin American liberation theology and the closely related Dalit theology of the Indian subcontinent. It has also been expressed by modern European theologians, such as Paul Tillich and Elisabeth Schüssler Fiorenza. <a href="https://www.runrig.org/posts/hedgerows.html#fnref33" class="footnote-backref">↩︎</a></p></li><li id="fn34" class="footnote-item"><p>Ibid., 4. <a href="https://www.runrig.org/posts/hedgerows.html#fnref34" class="footnote-backref">↩︎</a></p></li><li id="fn35" class="footnote-item"><p>Muldoon, <em>Platform Socialism</em>, 18. <a href="https://www.runrig.org/posts/hedgerows.html#fnref35" class="footnote-backref">↩︎</a></p></li><li id="fn36" class="footnote-item"><p>Ibid. <a href="https://www.runrig.org/posts/hedgerows.html#fnref36" class="footnote-backref">↩︎</a></p></li><li id="fn37" class="footnote-item"><p>The WTO History Project, <a href="https://depts.washington.edu/wtohist/orgs.htm" target="_blank" rel="noreferrer">"Organizations Opposed to the WTO"</a> <a href="https://www.runrig.org/posts/hedgerows.html#fnref37" class="footnote-backref">↩︎</a></p></li><li id="fn38" class="footnote-item"><p>C-SPAN's video recording and transcript of the <a href="https://c-span.org/video/?153921-1/globalization-world-trade-organization" target="_blank" rel="noreferrer">30 Nov 1999 debate at Seattle Town Hall</a>, moderated by Paul Magnusson, correspondent for <em>Business Week</em>. <a href="https://www.runrig.org/posts/hedgerows.html#fnref38" class="footnote-backref">↩︎</a></p></li><li id="fn39" class="footnote-item"><p><a href="https://web.archive.org/all/20000816130236/http://seattle.indymedia.org/about.php3" target="_blank" rel="noreferrer">"Independent Media Center (Seattle) Mission Statement"</a>, <a href="http://seattle.indymedia.org/about.php3" target="_blank" rel="noreferrer">http://seattle.indymedia.org/about.php3</a> (archived 2000 Aug 16). <a href="https://www.runrig.org/posts/hedgerows.html#fnref39" class="footnote-backref">↩︎</a></p></li><li id="fn40" class="footnote-item"><p><a href="https://vimeo.com/223772965" target="_blank" rel="noreferrer"><em>Showdown In Seattle</em></a>, documentary made in collaboration by Paper Tiger TV, Independent Media Center, Media Island Int'l et al. <a href="https://www.runrig.org/posts/hedgerows.html#fnref40" class="footnote-backref">↩︎</a></p></li><li id="fn41" class="footnote-item"><p><a href="https://www.democracynow.org/2019/11/27/indymedia_independent_media_seattle_wto_1999" target="_blank" rel="noreferrer">"“Don’t Hate the Media, Be the Media”: Reflections on 20 Years of Indymedia, a Radical Media Movement"</a> <a href="https://www.runrig.org/posts/hedgerows.html#fnref41" class="footnote-backref">↩︎</a></p></li><li id="fn42" class="footnote-item"><p>Eva Giraud, <a href="https://doi.org/10.1177/1354856514541352" target="_blank" rel="noreferrer">"Has radical participatory online media really ‘failed’? Indymedia and its legacies"</a>, <em>Convergence</em>, 20(4), 419-437. <a href="https://www.runrig.org/posts/hedgerows.html#fnref42" class="footnote-backref">↩︎</a></p></li><li id="fn43" class="footnote-item"><p><em>Portland Independent Media Center</em>, <a href="https://web.archive.org/web/20071218073332/http://portland.indymedia.org/en/2005/08/322550.shtml" target="_blank" rel="noreferrer">"Co-ops making history! World's first open-source POS system at People's Food Co-op."</a> <a href="https://www.runrig.org/posts/hedgerows.html#fnref43" class="footnote-backref">↩︎</a></p></li><li id="fn44" class="footnote-item"><p>Co-operative Operational Retail Environment, IS4C (source code repository), <a href="https://github.com/CORE-POS/IS4C" target="_blank" rel="noreferrer">https://github.com/CORE-POS/IS4C</a>. <a href="https://www.runrig.org/posts/hedgerows.html#fnref44" class="footnote-backref">↩︎</a></p></li><li id="fn45" class="footnote-item"><p>John Perry Barlow, <a href="https://www.eff.org/cyberspace-independence" target="_blank" rel="noreferrer">"A Declaration of the Independence of Cyberspace"</a>, The Electronic Frontier Foundation. <a href="https://www.runrig.org/posts/hedgerows.html#fnref45" class="footnote-backref">↩︎</a></p></li><li id="fn46" class="footnote-item"><p>April Glaser, <a href="https://logicmag.io/bodies/another-network-is-possible/" target="_blank" rel="noreferrer">"Another Network is Possible"</a>, <em>Logic(s)</em> (3 Aug 2019) <a href="https://www.runrig.org/posts/hedgerows.html#fnref46" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/hedgerows.html#fnref46:1" class="footnote-backref">↩︎</a></p></li><li id="fn47" class="footnote-item"><p><a href="https://web.archive.org/web/20181015082155/http:/www.csuchico.edu/zapatist/HTML/Archive/Communiques/ccri_encount_aug.html" target="_blank" rel="noreferrer">"Closing Words of the EZLN at the Intercontinental Encounter- 2nd Declaration of La Realidad" (archived English translation)</a>; see also the <a href="https://enlacezapatista.ezln.org.mx/1996/08/03/segunda-declaracion-de-la-realidad-por-la-humanidad-y-contra-el-neoliberalismo/" target="_blank" rel="noreferrer">original in Spanish</a>. The <a href="https://schoolsforchiapas.org/library/1st-declaration-la-realidad-humanity-neoliberalism/" target="_blank" rel="noreferrer"><em>First Declaration of La Realidad</em></a> (<a href="https://enlacezapatista.ezln.org.mx/1996/01/01/primera-declaracion-de-la-realidad-contra-el-neoliberalismo-y-por-la-humanidad/" target="_blank" rel="noreferrer">Spanish orig.</a>), published January 1996, was essentially the announcement for the <em>encuentro</em> to be held later that summer. As Monty Neill recalls in "Encounters in Chiapas" (<em>Midnight Notes</em> #13), Marcos expressed his doubts that anyone would show up. It was the first such attempt to convene their supporters outside of Mexico, the majority of whom had just communicated online until then. The response exceeded most expectations. <a href="https://www.runrig.org/posts/hedgerows.html#fnref47" class="footnote-backref">↩︎</a></p></li><li id="fn48" class="footnote-item"><p>Between 2001 and 2009, <em>Fast Food Nation</em> and <em>Omnivore's Dilemma</em> both ranked in the top 10 on the NY Times Best Sellers for Non-Fiction while their respective film adaptations each enjoyed a major theatrical release. <a href="https://www.runrig.org/posts/hedgerows.html#fnref48" class="footnote-backref">↩︎</a></p></li><li id="fn49" class="footnote-item"><p>Looming large among these victories at the dawn of the millennium, the USDA's National Organic Program was entered into the <a href="https://www.federalregister.gov/documents/2000/12/21/00-32257/national-organic-program" target="_blank" rel="noreferrer">Federal Register</a> on December 21, 2000, with its full suite of regulatory measures becoming effective law on February 20, 2001. While it displeased many grassroots organic activists for its concessions to Big Ag, it was undeniably a win. There were also modest achievements in various Farm Bills during this time, though also some setbacks in court, such as the multiple rulings in favor of Monsanto's seed patents. <a href="https://www.runrig.org/posts/hedgerows.html#fnref49" class="footnote-backref">↩︎</a></p></li><li id="fn50" class="footnote-item"><p>Apart from the antitrust ruling against Microsoft in 1998, which was something of a Pyrrhic victory for open source in the Browser Wars, the most significant successes for FOSS were achieved not in Washington, but on Wall Street. Red Hat's fabled IPO in 1999 was a bellweather for the eventual dominance that Linux would achieve in the realm of cloud computing and other technologies deployed at-scale and industry-wide. It's also debateable whether free culture made significant gains beyond generally raising awareness. Despite a modicum of publicity, the majority of their legal battles were still losses. <a href="https://www.runrig.org/posts/hedgerows.html#fnref50" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Illegible Agriculture]]></title>
        <id>https://www.runrig.org/posts/illegible-agriculture.html</id>
        <link href="https://www.runrig.org/posts/illegible-agriculture.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2025-07-07T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Why technocrats so often try (and fail) to simplify farming's essential complexity]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Illegible Agriculture</h1><p><strong>Why technocrats so often try (and fail) to simplify farming's essential complexity</strong></p></header><div style="position:relative;" class="vp-doc _posts_illegible-agriculture" data-v-e6f2a212=""><div><p>In the latter half of 2022, I helped organize a short series of open design sessions that focused on the information and communication systems of multi-farm CSAs and food hubs. It was a joint effort between the <a href="https://goatech.org/" target="_blank" rel="noreferrer">GOAT community</a> and the short-lived yet influential <a href="https://rvamag.com/eatdrink/goodeats/from-tech-to-independent-farming-chris-newman-of-sylvanaqua-farms-and-his-journey-to-food-sovereignty-and-advocacy.html" target="_blank" rel="noreferrer">Skywoman</a> project that Chris Newman had spearheaded. We first interviewed the <a href="https://richlandgro-op.com/" target="_blank" rel="noreferrer">Richland Gro-Op</a>, an urban farmers' cooperative based on the <a href="https://osumarion.osu.edu/alumni-initiatives/initiatives/microfarm.html" target="_blank" rel="noreferrer">Microfarm</a> model developed at Ohio State by Kip Curtis. We followed that up by talking to Tianna Kennedy from <a href="https://www.the607csa.com/" target="_blank" rel="noreferrer">the 607 CSA</a>, who had built up an impressive distribution network as an emergency response to COVID-19, sourcing from roughly a dozen farms across Upstate New York and supplying up to 50 drop-off sites throughout the Hudson Valley and New York City. Both organizations are extraordinary examples of how the operational and logistical complexity of a supply chain can be successfully managed by means of thorough local knowledge combined with a well-established network of trust.</p><p>Documenting their procedures was the primary goal and accomplishment of those sessions, and all the notes and interview materials are available on GitHub as the <a href="https://github.com/skywoman/multifarm-aggregation-info-arch#technical-interviews--open-design-sessions" target="_blank" rel="noreferrer">MAIA Project</a>, for anyone who still wants to learn from them. In addition to that central aim, I hoped the sessions might also act as a proving ground for some ideas I was developing about participatory software development, shared knowledge systems, and some specific design concepts that would eventually became the basis for Runrig. They were not yet fully formed, but the main impetus was there, as I wrote in the <a href="https://jgaehring.com/blog/platform-coop" target="_blank" rel="noreferrer">project announcement</a>:</p><blockquote><p>The data underpinning networks of agricultural production and food distribution are so inextricably complex; it is no accident that this complexity only skyrockets when due respect and full equity is granted to every person and creature involved, as well as the land and overall ecology that contributes to feeding a community. It is a reflection of the social and cultural complexities underpinning how we eat, grow and relate to one another and our environment. I don't think there can be a just and equitable software system, capable of handling all that informational complexity, if it doesn't have social and ecological cooperation baked right into the design and methodology of the system itself.</p></blockquote><p>I argued that VC-funded startups could never be expected to deliver technology with the necessary breadth and depth of coverage while also maintaining fidelity to real-world food systems.</p><p>As the interviews were wrapping up, Chris Newman offered further insight into <a href="https://web.archive.org/web/20240303180714/https://www.skywoman.community/post/choosing-software-the-case-for-using-erp-crm-scm-to-scale-farms" target="_blank" rel="noreferrer">why off-the-shelf software so often fails</a> to solve the informational challenges of diversified agriculture and short supply chains. He relayed a complaint from another farmer, who had soured on ag-tech startups claiming that their software would cure all the logistical pains that ailed them. When these schemes inevitably came up short, the "solutions experts" insisted there was nothing wrong with the software's design or implementation. Instead, the fault laid in their own farming practices. These software engineers had determined that the farm itself was unjustifiably complex and in drastic need of simplification. Newman, who himself worked as a software engineer for many years prior to farming, points out what a "big red flag" this ought to be seen as:</p><blockquote><p>Software companies are not in the food business, they don't have any business telling you how to run yours, and if they do, they're deliberately attempting to throttle what works for you in order to make you work for them.</p></blockquote><p>In some ways, this is emblematic of the "lossy" quality of software abstractions that try to oversimplify intrinsically complex systems, thereby losing some critical bits of information. Since <a href="https://en.wikipedia.org/wiki/No_Silver_Bullet" target="_blank" rel="noreferrer">at least the mid-1980s</a>, software developers and information architects have tried to distinguish between <em>essential complexity</em>, which is inherent to the user domain or business logic, and <em>accidental complexity</em>, which is incurred by the very fact of adding software into the mix. For our interests, everything entailed by the task of farming is essential complexity, while technical details, such as the way an app connects to the network or to a database, is all accidental complexity. It is the job of good design to find ways of reducing accidental complexity, even if it can never be eliminated entirely. Good software, in turn, just gets out of the way so the domain expert – i.e., the farmer or food worker – can reason more clearly about the essential complexity without distraction. The software's role is to be a better crop planning notebook or a better store checkout process, not a better farmer or better food worker. Deliberately targeting essential complexity for removal, as the developers recommended in Newman's anecdote, can only be interpreted as a flaw in the design. At least, that's the most charitable way of explaining why proprietary software so often fails to meet a farmer's needs.</p><p>To view it from a more overtly political perspective, we might interpret the elimination of essential complexity as technocrats imposing <em>legibility</em> upon a socially and ecologically diverse food system, which would otherwise remain unintelligible to your average engineer or startup founder. Legibility is a concept <a href="https://theanarchistlibrary.org/library/james-c-scott-seeing-like-a-state" target="_blank" rel="noreferrer">originated by James C. Scott</a> to analyze the failures of top-down state planning, from the Soviet Union's collectivization of agriculture to the urban renewal projects of Le Corbusier and Robert Moses. It's an interpretive lens employed in many anarchist critiques of both capitalist and socialist forms of state coercion. Marxists might observe, meanwhile, that material goods and services must undergo a distinctly <a href="https://www.marxists.org/archive/marx/works/1857/grundrisse/ch01.htm#loc3" target="_blank" rel="noreferrer">Hegelian form of abstraction</a> in order to be made exchangeable as commodities under capitalism. In his book <a href="https://www.techwontsave.us/episode/97_envisioning_platform_socialism_w_james_muldoon" target="_blank" rel="noreferrer"><em>Platform Socialism</em></a>, James Muldoon applies this line of thinking to what he calls <em>data commodity fetishism</em>, defining it as "the perception of certain digital relationships between people (especially for communication and exchange) as having their value based not on the social relationships themselves but on the data they produce." It's part of Big Tech's rent-seeking enterprise, whereby they insert themselves as the brokers of our everyday social and economic exchanges, whether that's with our nextdoor neighbors or remote customers, distant friends or close family members. Tech platforms make themselves indispensable that way, not because they add anything of value, but because they've locked down and monopolized all other digital modes of exchange.</p><p>Each of these interpretations offers unique insights of its own, but altogether I think they gesture towards the same general conclusion. The tendency of proprietary software to oversimplify complex food systems is not meant to facilitate or improve upon existing foodways – i.e., how a community grows its food in accordance with local customs and conditions. Rather, it is meant to render the labor, knowledge, and produce of that community more suitable for mass consumption and capital accumulation. Any costs incurred by shoving inherently complex and richly organic material into simpler commodity forms are deflected back onto the community itself. Investors won't ever feel those costs, that's for sure, which is entirely by design. Of all these takes, I think Chris Newman still summed it up best, that software companies really just want "to throttle what works for you in order to make you work for them."</p><p>Meanwhile, the real challenge remains: how can diverse food communities bring their full capacities to bear upon the production and deployment of appropriate technologies, which meet their practical needs but preserve all the essential complexity of their social relations and physical environment? And for any of that to work – because at the moment we do still live under capitalism, with all its rentiers and artificial scarcities – how do we manage the added costs of developing and maintaining such technology?</p><p>In very broad strokes, I attempted to address those questions in <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html">The Runrig Plan</a>, which I first published once the final interviews for the MAIA Project concluded. Over the course of the intervening two years, I've continued to explore particular aspects of the designs I proposed there. I've also been in constant discussion with farmers, community leaders, and other free software developers about the merits, drawbacks, and tradeoffs of various technology stacks, differing approaches to their implementation, and so forth.</p><p>Better alternatives are well within reach, but before I elaborate on them, I need to delve just a little bit deeper into the hidden assumptions that underwrite so many of these complexity-erasing abstractions. Chief among them is what startups like to call <em>scalability</em>. It is assumed to be at once necessary to the success of any respectable software project, while also attainable with zero loss of fidelity to the domain model. The perceived need to scale can cause even community-based, free software projects with the purest intentions to perpetuate the same anti-patterns as VC-funded, proprietary software startups. Without scaling, it is argued, there is no other way of making free software both accessible and affordable to the wider masses. That is a noble aim, truly, and I'll make the case that it's still quite feasible, but that "scaling" is the wrong metaphor for the job. Far more often, scalability only leads to bad design choices that do, in fact, erase essential aspects of our food systems' social and ecological complexity. In order to reach a broader base of people and accommodate a more varied array of user scenarios, all while preserving the full range of complexity they inhabit, free software needs new metaphors and new abstractions to build upon. That will be the topic of my next article, so do stay tuned.</p></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Roadmap for 2024]]></title>
        <id>https://www.runrig.org/posts/roadmap-2024.html</id>
        <link href="https://www.runrig.org/posts/roadmap-2024.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2023-12-17T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[This roadmap is being presented in order to provide a more intentional, structured exposition of Runrig's short and long term goals.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Roadmap for 2024</h1></header><div style="position:relative;" class="vp-doc _posts_roadmap-2024" data-v-e6f2a212=""><div><p>This roadmap is being presented in order to provide a more intentional, structured exposition of Runrig's short and long term goals. It is not, however, meant to be a static declaration of Runrig's purpose or motivations. It's a starting point, not just for the year 2024 but for each and every time we come together in community, and only for as long as we collectively choose not to plot another course.</p><p>Here's the TL;DR of what's covered:</p><ul><li>Acknowledgement of <a href="https://www.runrig.org/posts/roadmap-2024.html#lessons-learned-in-2023">some mistakes I've made</a> (and hopefully learned from) over the last year.</li><li>A tentative <a href="https://www.runrig.org/posts/roadmap-2024.html#three-phase-organizing-model-or-business-plan">3-phase organizing model or "business plan"</a>, or at least some targets to nudge Runrig towards being more sustainable and not strictly volunteer based.</li><li>An outline of <a href="https://www.runrig.org/posts/roadmap-2024.html#projects-for-2024">specific project, goals and stuff we can build in 2024</a>, in service of the previous point.</li><li>A new schedule and format for <a href="https://www.runrig.org/posts/roadmap-2024.html#building-community">workshops and other community building activities</a>.</li></ul><p>Feel free to jump to the sections most relevant to your interests.</p><p>There will be a live-streamed &amp; recorded presentation that covers this roadmap and what else lies ahead for Runrig in 2024 on <strong>Friday, Jan 5, 2pm Eastern Time</strong>. See the <a href="https://events.nixnet.services/events/a25c39b9-35dc-46c2-aab7-fd06cabc4a97" target="_blank" rel="noreferrer">event page</a> for calendar options and the call link, or find the live-stream and recording on the <a href="http://www.youtube.com/@RunrigCoop" target="_blank" rel="noreferrer">Runrig YouTube Channel</a>.</p><p>I'm also seeking feedback, suggestions, and other comments on this and Runrig more generally, which can be posted on the <a href="https://github.com/orgs/runrig-coop/discussions/7" target="_blank" rel="noreferrer">GitHub Discussion</a> for this this roadmap.</p><h2 id="lessons-learned-in-2023" tabindex="-1">Lessons Learned in 2023 <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#lessons-learned-in-2023" aria-label="Permalink to &quot;Lessons Learned in 2023&quot;">​</a></h2><p>Runrig got started in late-2022 first as a series of private journal entries and one-on-one conversations with friends, then as a private GitHub repo labeled <code>draft-proposal</code>, which for convenience sake I eventually made public. For me it was an exercise in articulating the kind of tools I wanted to build, the principles that would guide that work, and the overall culture of care I wished to surround it all. Ultimately, I was just trying to answer the question: What would I want an ag-tech worker's co-op to look like, based on my own experiences working in agriculture, food service and open source software?</p><p>For the past year, Runrig has remained in that same exploratory state. Designs have evolved, plans have changed, and by its very nature as a method of simple exploration, it has been anything but stagnant. Yet having never committed to a firm course of action, I struggle to see how its fundamental disposition has progressed at all beyond those early drafts and conversations from one year ago. All may be flux, but it still feels like stepping into the same river.</p><p>I've hesitated to center the initial concept and motivations for Runrig out of a concern that mine or anyone else's perspective might come to dominate and push out other deserving voices. While I wasn't exactly wrong in that impulse to make this an open and shared space, I was wrong about what it means to be truly open and sharing. I was reluctant to fully commit myself and take ownership of the project, because I knew how hard it can be to let go of that control as others come onboard and take a shared interest in its success. Avoiding all ownership and control, however, was no better a response than ignoring their perils entirely. The hardest thing, I realize now, is to accept accountability and be willing to commit to stewarding Runrig towards its next phase — call that "ownership," if you will — even while acknowledging that at some point I may have to let go of that control and either share or wholly cede its ownership to others. I hope when that time comes, I can do so willingly and joyfully, just like so many of my peers and antecedents have gifted me the dearly earned fruits of their own past labors.</p><p>With that in mind, I want to continue building those relationships, grounded in trust, which are so necessary to make this more than just a vanity project or wayward social experiment. And to do that, I intend to refocus my efforts towards developing the infrastructure and resources required to follow through on my commitments and solidify those relationships. While I still hope Runrig can provide a space for others and myself to play with new ideas and experiments, for at least the next year I've laid out a more concrete path of development, which follows below. Likewise, while I want our workshops to remain free and open to new projects and discussions, I'll strive to provide more intentionality, structure and focus to those events, which I believe will go a long way to making them more welcoming and inclusive to all.</p><p>I'm also making a conscious effort to use the first-person singular here. (Hi, it's Jamie! 👋🏻🦤). I just learned that the really hardcore grammatical term for that is <em>clusivity</em>, where "we" is <em>inclusive</em> and "I" is <em>exclusive</em>. I like to strive for inclusivity always, but this whole process — from a year ago to five minutes ago when I looked that up — has me realizing that sometimes the first step in bringing more people into unity can be to step forward and introduce yourself, as your totally unique self, before stepping back into your role within the larger group. Not always, but sometimes, like now. Plus, that whole "royal we" thing, grammatically inclusive or not, can come across pretty authoritarian and not at all welcoming. I know that's all a bit off-topic, but despite wishing otherwise and acknowledging just how many awesome people have contributed to this already, Runrig is still 90% just Jamie talking into the void, at least most weeks. And that's cool, but to make this a space where others not only feel welcome but have a sense of shared ownership, I think that takes a little more candor than I've been offering to date.</p><h2 id="three-phase-organizing-model-or-business-plan" tabindex="-1">Three-Phase Organizing Model or "Business Plan" <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#three-phase-organizing-model-or-business-plan" aria-label="Permalink to &quot;Three-Phase Organizing Model or &quot;Business Plan&quot;&quot;">​</a></h2><p>In the preliminary draft of <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#main-legal-entities-constituting-the-runrig-system">"Appendix: Ecology" § "Main Legal Entities Constituting the Runrig System"</a> in <em>The Runrig Plan</em>, I outlined 3 types of legal entities and 3 cooperative membership classes:</p><ol><li>A <strong>worker cooperative</strong> of engineers, designers and system administrators (aka, <em>worker members</em>), responsible for the building out and maintaining platform cooperatives' core services and end user applications.</li><li><strong>Platform cooperatives</strong> customized to meet the needs of each regional foodshed, providing a home platform for farmers and food workers (aka, <em>service members</em>) to access Runrig's network-based services and to host other FOSS cloud services.</li><li>A <strong>data cooperative</strong> or <strong>data trust</strong>, whose members are users of the global data provider, which in turn serves as a centralized repository of all users data. These <em>data members</em> retain full control over how their own data is accessed, modified and shared, but in addition they enjoy governance rights over the management and administration of the provider's infrastructure, development, pricing, etc.</li></ol><p>I've re-ordered them here to reflect the order in which they will most likely be incorporated. The worker cooperative, of which I myself hope to become a worker-member, would likely come first since it's needed to build the infrastructure for the rest. The latter two may develop in parallel, depending upon needs, but for now I think its safe to say individual platform cooperatives represent less complexity to implement, and so those I've ordered second with the data co-op or trust third.</p><p>It seems sensible that the Runrig worker cooperative, as the leading cusp of this triangular cooperative arrangement, would adopt a business plan to be implemented in three corresponding phases:</p><ul><li><em>Phase One:</em> <strong>Middleware, a.k.a. "glue services"</strong><ul><li>Targeted interventions that can catch the spillover of <a href="https://github.com/search?type=issues&amp;q=label%3Aenhancement+label%3Awontfix+is%3Aclosed" target="_blank" rel="noreferrer"><code>wontfix</code></a> issues or otherwise unfulfilled feature requests from more mature FOSS projects, while also providing reusable <a href="https://www.redhat.com/en/topics/middleware/what-is-middleware" target="_blank" rel="noreferrer">middleware</a> and extensions to connect previously incompatible APIs and services.</li></ul></li><li><em>Phase Two:</em> <strong>The One-stop Platform Co-op Shop™️</strong><ul><li>Technical assistance and consulting for the deployment and administration of platform cooperatives. This is analogous to the classic "web dev shop," particularly the diverse community of Drupal developers and consultants. These shops have proven that such an ecosystem can not only be sustained by free and open source software, even licensed under the "copyleft" GPL, but that it can positively thrive on account of the virtuous cycles that arise from the software commons and a precompetitive community of practice. The same potential exists for the semantic web and platform co-ops. To help foster its emergence, Runrig can provide a wide range of solutions: from fully managed hosting and technical support, to the hands-off delivery of complete systems that farms and food businesses can run for themselves; from crowdfunded feature enhancements and major upgrades for core libraries and services, to the same kind of small integrations of <em>Phase One</em> and special plugins that may only suit one client's needs; everything from the turnkey to the bespoke.</li></ul></li><li><em>Phase Three:</em> <strong>One Big Data Co-op</strong> 🐈‍⬛ <ul><li>Communally owned and controlled infrastructure for food sovereignty in the form of a cooperatively owned <a href="https://www.adalovelaceinstitute.org/report/legal-mechanisms-data-stewardship/" target="_blank" rel="noreferrer">data cooperative or trust</a>. This infrastructure is essentially what's termed the <em>data provider</em> in <em>The Runrig Plan</em> (see <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#three-layers-of-autonomy">"Three Layers of Autonomy"</a>). The most potential may lie in the form of a large Solid Pod Provider or other Linked Data Platform, but there may also be benefits to hosting FOSS alternatives to more conventional cloud services.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/roadmap-2024.html#fn1" id="fnref1">[1]</a></sup> To be clear, complete ownership, governance, and control of these utilities will belong the co-op members — ie, the farmers, food workers, small businesses and end consumers who store their data there — not to Runrig. However, Runrig can be contracted to administer, maintain and further develop that infrastructure on behalf of its members. There may be other peripheral services required to deploy such infrastructure and optimize its connections to the platform services of <em>Phase Two</em>.</li></ul></li></ul><p>Preliminary to <em>Phase One</em> and the legal incorporation of the worker cooperative, it seems wise to delineate a <em>Phase Zero</em>, while we're still an entirely volunteer effort and prior to any financial transactions:</p><ul><li><em>Phase Zero:</em> <strong>Reference Implementations</strong><ul><li>Before taking any contracts or pursuing grants for the following phases, build out one or two reference implementations or proofs-of-concept to test the viability of the model at each phase of development; namely: <ul><li><a href="https://www.runrig.org/posts/roadmap-2024.html#local-applications--middleware">Local Applications &amp; Middleware</a> (<em>Phase One</em>)</li><li><a href="https://www.runrig.org/posts/roadmap-2024.html#integration-with-third-party-apps--services">Integrations with Third-party Apps &amp; Services</a> (<em>Phase Two</em>)</li><li><a href="https://www.runrig.org/posts/roadmap-2024.html#hosting--data-services">Hosting &amp; Data Services</a> (<em>Phase Three</em>).</li></ul></li></ul></li></ul><p>Of course, at such an early stage the reference implementations for the data provider may need to be scaled back considerably, or merely a proof-of-concept using an already available service, such as <a href="https://www.inrupt.com/" target="_blank" rel="noreferrer">Inrupt</a>.</p><p>The overall intention behind this three-phase plan is to provide a path for iterative development across the entire stack. The fact that Runrig's smallest, most rudimentary components are at the same time its most atomic and self-contained components is no accident: this is precisely what is meant by <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#three-layers-of-autonomy">"Three Layers of Autonomy"</a> in <em>The Runrig Plan</em> and why I think it offers unique advantages that cannot be achieved by your average VC-funded, proprietary tech startup.</p><h2 id="projects-for-2024" tabindex="-1">Projects for 2024 <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#projects-for-2024" aria-label="Permalink to &quot;Projects for 2024&quot;">​</a></h2><p>In the interest of getting Runrig past <em>Phase Zero</em> of the business plan, the main goal for 2024 is to build the reference implementations for the remaining phases. By no means is it intended to complete all of the implementations listed below; just one or two can be selected for each proposed phase, while the others can wait until funding is secured for that phase. I list them all here for context and to give a better sense of the potential for the years ahead.</p><h3 id="local-applications-middleware" tabindex="-1">Local Applications &amp; Middleware <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#local-applications-middleware" aria-label="Permalink to &quot;Local Applications &amp; Middleware&quot;">​</a></h3><p><strong>Reference implementations for <em>Phase One</em>:</strong></p><ul><li><a href="https://github.com/runrig-coop/early-warning-system/" target="_blank" rel="noreferrer">Early Warning System</a></li><li>Furlong (provisional name for a potential <a href="https://github.com/runrig-coop/early-warning-system/discussions/20" target="_blank" rel="noreferrer">system tray utility</a>)</li><li><a href="https://docs.google.com/document/d/1MVad6LtQJ3Ocmgx1wyTtYEdpAgsHNMb0sVu5lQl3ee8/" target="_blank" rel="noreferrer">Projection Engine</a><ul><li>Dynamic Yield Coefficients (possible standalone lib)</li></ul></li></ul><p>Implementation of the Early Warning System is already well underway, as a part of the <a href="https://github.com/runrig-coop/open-design-workshops/blob/f1cab5354f6726b361894687e42692c062054448/rgo-crop-plan-auditing/README.md" target="_blank" rel="noreferrer">Crop Plan Auditing System</a> we modelled for the <a href="https://richlandgro-op.com/" target="_blank" rel="noreferrer">Richland Gro-Op</a> (RGO). The underlying Tauri app we've built could also be adapted to a general purpose system tray utility, that could provide notifications and link to third-party applications as a part of <em>Phase Two</em>.</p><p>Another concept we explored as a part of the Crop Plan Auditing System was the Dynamic Yield Coefficient, or DYC. It's fairly straight-forward, just a ratio expressing how many pounds of produce a given variety yields per bed-foot (or row-foot) planted. The challenge is in allowing the crop plan manager to adjust that ratio manually while ensuring that changes are propagated to all relevant computed data based on that ratio. In RGO's case, that propagation is achieved via spreadsheet cells and formulae, a fairly brittle system, but something we hoped to ameliorate by integrating her crop plan with a NocoDB instance or some other syncing mechanism.</p><p>Conceptually, this is all very closely related to an earlier NSF grant proposal that was never awarded for the Projection API, although I believe in our scenario it would be better termed the <a href="https://docs.google.com/document/d/1MVad6LtQJ3Ocmgx1wyTtYEdpAgsHNMb0sVu5lQl3ee8/" target="_blank" rel="noreferrer">Projection Engine</a>. This could essentially be a set of libraries for running constrained optimizations on crop plan data, something David Wright and I discussed might also be aided by his <a href="https://github.com/Wright4TheJob/ProcessScheduler-rs" target="_blank" rel="noreferrer">Rust port</a> of <a href="https://github.com/tpaviot/ProcessScheduler" target="_blank" rel="noreferrer">ProcessScheduler</a>. These utilities and the Projection Engine might not prove very useful in isolation, but could be incredibly powerful if we integrate with Qrop/Brinjel or Open Food Network in <em>Phase Two</em>.</p><h3 id="integrations-with-third-party-apps-services" tabindex="-1">Integrations with Third-party Apps &amp; Services <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#integrations-with-third-party-apps-services" aria-label="Permalink to &quot;Integrations with Third-party Apps &amp; Services&quot;">​</a></h3><p><strong>Integrations with the following applications for <em>Phase Two</em>:</strong></p><ul><li><a href="https://qrop.frama.io/" target="_blank" rel="noreferrer">Qrop</a>/<a href="https://brinjel.com/" target="_blank" rel="noreferrer">Brinjel</a></li><li>farmOS, Field Kit &amp; Survey Stack</li><li>Open Food Network</li><li><a href="https://www.nocodb.com/" target="_blank" rel="noreferrer">NocoDB</a>/Airtable</li></ul><p>Brinjel (soon to supersede Qrop) is a desktop crop planning application sponsored by the French cooperative <a href="https://latelierpaysan.org/" target="_blank" rel="noreferrer">L'Atelier Paysan</a>, and from the looks of it, they intend to provide cloud services once Brinjel is ready for general release. They're both licensed under the GPL/AGPL and are very well designed. Because Qrop is a desktop app running a simple SQLite database, it should be possible to integrate it with the Early Warning System.</p><p>Integration with farmOS and Field Kit, of course, should be fairly straight-forward. With <a href="https://github.com/farmOS/farmOS.js" target="_blank" rel="noreferrer">farmOS.js</a> we could stand up a really simple Node server to provide networked storage, or we can try adapting the <a href="https://farmos.org/model/" target="_blank" rel="noreferrer">farmOS Data Model</a> to the Solid Protocol to provide network availability. Or both! Survey Stack can also provide some nice integrations without too much additional effort, since it also incorporates the farmOS.js client and modelling libraries.</p><p>I'm likewise very keen to seek integrations with Open Food Network, though this may not have any immediate advantages and I'm far less familiar with their API than I am with farmOS.</p><p>If a clear need arises, we can also try to connect the Early Warning System or other local applications to Airtable's REST API, or a <a href="https://www.nocodb.com/" target="_blank" rel="noreferrer">NocoDB</a> instance. In the latter case, we could just try connecting to <a href="https://nococloud.dev/" target="_blank" rel="noreferrer">NocoDB Cloud</a>, their hosted service, or our own instance, if we get one deployed as a part of <em>Phase Three</em>.</p><h3 id="hosting-data-services" tabindex="-1">Hosting &amp; Data Services <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#hosting-data-services" aria-label="Permalink to &quot;Hosting &amp; Data Services&quot;">​</a></h3><p><strong>Proofs-of-concept for <em>Phase Three</em> hosting solutions:</strong></p><ul><li><a href="https://docs.nocodb.com/getting-started/self-hosted/installation" target="_blank" rel="noreferrer">NocoDB hosting</a></li><li><a href="https://solidproject.org/users/get-a-pod" target="_blank" rel="noreferrer">Solid Pods</a></li><li>Collaboration w/ <a href="https://coopcloud.tech/" target="_blank" rel="noreferrer">Co-op Cloud</a></li></ul><p>The potential of NocoDB is something that has appealed to me since a round of discussions with Tianna Kennedy of 607 CSA and the Catskills Agrarian Alliance. As a part of Skywoman's <a href="https://github.com/skywoman/multifarm-aggregation-info-arch" target="_blank" rel="noreferrer">MAIA Project</a>, we investigated a range of tech solutions but concluded that her team was already such a well-oiled machine that they really needed the full power of a spreadsheet application that they had full control over. Their one and only complaint was due to the brittleness of connecting many separate files each with potentially dozens of sheets, made all the more challenging when it came to importing new data from third-party applications.</p><p>One solution I proposed, but never really explored was what I called the "source-n-sink" spreadsheets or tables. It could work with spreadsheets, but seemed ideal to use with a more robust "no-code" database like Airtable, Notion or NocoDB. Here are my original notes:</p><blockquote><p>3 part deliverable:</p><ul><li>Script* for querying orders from ecommerce platforms (eg, Squarespace) and dump the raw data into a "Source Table" in Airtable. Immutable, append-only.</li><li>Airtable template(s) for "Sink Table(s)", which Tianna and others can use, change, manipulate, etc, but which draw on the raw "Source Tables" without changing them.</li><li>SOP for 607 CSA and other farms who want to replicate the process.</li></ul><p>* = It's possible this script could be based on or integrated with Chris's <a href="https://github.com/skywoman/eddie" target="_blank" rel="noreferrer"><code>eddie</code> scripts</a>.</p></blockquote><p>I've come to think more that this kind of solution could also provide a sort of stop-gap to the kinds of challenges that Richland Gro-Op faces as well.</p><p>Ultimately, it's probably best to get as much data into more portable, semantic formats, like the kinds supported by the Solid Project. We could test on existing Solid <a href="https://solidproject.org/users/get-a-pod#get-a-pod-from-a-pod-provider" target="_blank" rel="noreferrer">pod providers</a> like <a href="https://www.inrupt.com/" target="_blank" rel="noreferrer">Inrupt</a>, or stand up our own <a href="https://communitysolidserver.github.io" target="_blank" rel="noreferrer">Community Solid Server (CSS)</a> for testing.</p><p>Last but not least, all of these hosting scenarios could be greatly facilitated by collaborating with <a href="https://coopcloud.tech/" target="_blank" rel="noreferrer">Co-op Cloud</a>, who's lightyears ahead of us already in creating public interest infrastructure and what they call the <a href="https://coopcloud.tech/blog/federation-proposal/" target="_blank" rel="noreferrer">configuration commons</a>. They're really awesome people and tightly aligned with every single one of Runrig's core values. It would be to our great detriment not to seek a partnership with them and use their infrastructure wherever we can. They already have a <a href="https://recipes.coopcloud.tech/nocodb" target="_blank" rel="noreferrer">NocoDB recipe</a> and a <a href="https://recipes.coopcloud.tech/farmos" target="_blank" rel="noreferrer">farmOS recipe</a> as a part of their configuration library, and we could surely contribute more as we find our way through <em>Phase Three</em>.</p><h2 id="building-community" tabindex="-1">Building Community <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#building-community" aria-label="Permalink to &quot;Building Community&quot;">​</a></h2><p>It may be necessary to articulate a concrete program such as this in order to achieve Runrig's far-reaching goals, but I hope it will also invite new relationships, reinforce existing bonds, and strengthen the collaborative muscles required to make this a truly democratic and sustainable project.</p><h3 id="workshops-mutual-aid" tabindex="-1">Workshops &amp; Mutual Aid <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#workshops-mutual-aid" aria-label="Permalink to &quot;Workshops &amp; Mutual Aid&quot;">​</a></h3><div class="warning custom-block"><p class="custom-block-title">WARNING</p><p>The specific details of the workshop schedule and meeting links may be outdated but will not be updated. Please see the <a href="https://www.runrig.org/get-involved.html">get involved</a> page for the most current information about workshops and other events.</p></div><p>The Open Design Workshops so far have been held biweekly on weekend afternoons. While the consistency has been nice, I'd like to try alternating the days and times a bit to provide more varied opportunities for people coming from different timezones or who have a recurring obligation that might conflict with a single time and day of the week. We can always change it, but for now I'm scheduling it as 3 one-hour sessions each month:</p><table tabindex="0"><thead><tr><th style="text-align:left;">N<sup>th</sup> Day of the Month</th><th>Office Hrs</th><th>Workshop</th></tr></thead><tbody><tr><td style="text-align:left;">First Friday</td><td>7:30 - 8am ET</td><td>8am - 9am ET</td></tr><tr><td style="text-align:left;">Second Sunday</td><td>1:30 - 2pm ET</td><td>2pm - 3pm ET</td></tr><tr><td style="text-align:left;">Third Thursday</td><td>5:30 - 6pm ET</td><td>6pm - 7pm ET</td></tr></tbody></table><p>I am hoping the alliteration (plus how earlier days in the month correspond to earlier times of day) will make it <em>slightly</em> easier to remember, but of course I'll also keep a list of upcoming events posted here, as well as on the <a href="https://goatech.org/calendar/" target="_blank" rel="noreferrer">GOAT Community Calendar</a> (via Google Calendar). I'm also trying out <a href="https://events.nixnet.services/" target="_blank" rel="noreferrer">NixNix Events</a>, a federated instance of <a href="https://joinmobilizon.org/" target="_blank" rel="noreferrer">Mobilizon</a>, a social event planner made by <a href="https://framasoft.org/" target="_blank" rel="noreferrer">Framasoft</a> that supports the ActivityPub protocol. So you'll find all workshops posted in the <a href="https://events.nixnet.services/@runrig_workshops" target="_blank" rel="noreferrer">Runrig Workshops Group</a>.</p><p>The workshop format will be a little different as well. Instead of 2-hour free-form events, there will be a one hour workshop and/or livestream event with a set agenda, preceded by "office hours," where people can join half an hour early for more informal chat or to give-n-get a little Mutual Aid Tech Support (MATS). I'd like to see this kind of mutual aid work eventually have a greater share of the time, but it's an experiment and we'll just have to see how it plays out.</p><p>The workshop portion will be structured as a live-coding web stream, a report out on recent progress, or presentation on planned work for the future, depending on what projects we're working on and where they're at. In the beginning I suspect they'll be me talking and coding mostly, but as more people join we can shift to make it more participatory. I'll always try to leave time for introductions and check-ins/outs, and the main body of the agenda can always be adapted with group feedback in the time between one workshop and the next, based on what we're working on and who plans to attend. I'll try to post these to the <a href="http://www.youtube.com/@RunrigCoop" target="_blank" rel="noreferrer">Runrig YouTube Channel</a>, too, so if people want to watch later they can.</p><h3 id="education-training-research" tabindex="-1">Education, Training &amp; Research <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#education-training-research" aria-label="Permalink to &quot;Education, Training &amp; Research&quot;">​</a></h3><p>Along with the mutual aid work, I want to expand this to do events with more of a <a href="https://labornotes.org/2017/04/interview-organizing-learn-learning-organize" target="_blank" rel="noreferrer">popular education</a> component. I'd love Runrig to become a forum for regular skills-sharing sessions and technical training for those who have an interest in technology and who want to learn more, but also for community organizers and food producers to teach us techies and each other on the work their doing and how others can replicate democratic food distribution systems in their own communities. I believe it's also important to make space for political education, to really ground Runrig as a project for collective liberation, whether that takes the form of a book club movie watch parties, or some kind of trivia or game nights.</p><p>I've spoken with a few people about the idea of expanding <em>The Runrig Plan</em> into a robust design methodology, akin the <a href="https://agilemanifesto.org/" target="_blank" rel="noreferrer">Agile Manifesto</a> or the <a href="https://global.toyota/en/company/vision-and-philosophy/production-system/" target="_blank" rel="noreferrer">Toyota Production System</a>, but in conscious opposition to the capitalistic assumptions underpinning those philosophies. That kind of thing seems ripe for some form of <a href="https://en.wikiversity.org/wiki/Action_research" target="_blank" rel="noreferrer">Action Research</a> (or <a href="https://highlanderpar.org/resources/" target="_blank" rel="noreferrer">PAR</a> or <a href="https://www.detroiturc.org/about-cbpr/what-is-cbpr" target="_blank" rel="noreferrer">CBPR</a>). I've never done anything like that before personally, so it would have to be a truly self-organizing group effort, both for what we're trying to learn and how we're trying to learn it.</p><p>That will all take more than a year to come to fruition, but for now I think it's sufficient to look out for those opportunities when and where they arise. There are good reasons, after all, why "Education, Training, and Information" are together one of the International Cooperative Alliance's <a href="https://www.ica.coop/en/cooperatives/cooperative-identity" target="_blank" rel="noreferrer">Seven Cooperative Principles</a>:</p><blockquote><p>Cooperatives provide education and training for their members, elected representatives, managers, and employees so they can contribute effectively to the development of their co-operatives. They inform the general public - particularly young people and opinion leaders - about the nature and benefits of co-operation.</p></blockquote><h3 id="documentation-communication" tabindex="-1">Documentation &amp; Communication <a class="header-anchor" href="https://www.runrig.org/posts/roadmap-2024.html#documentation-communication" aria-label="Permalink to &quot;Documentation &amp; Communication&quot;">​</a></h3><p>In a similar way, I hope within a year or two to be able to walk through Luis Razeto's <a href="https://geo.coop/articles/how-create-solidarity-enterprise" target="_blank" rel="noreferrer"><em>How to Create a Solidarity Enterprise: A Theoretical-Practical Manual</em></a> with my fellow worker-members in preparation for incorporating the Runrig workers' co-op. Given our skill-sets with design and web development, it could be an opportunity to create a more interactive tool for completing the exercises and business planning steps in the manual, which we could gift back to the community. How we publish our own documentation could share some of that infrastructure as well, presenting an opportunity to create new tools for garnering user feedback and for more members of the community to take an active role in the development of their technology.</p><p>Finally, with these other efforts to provide more structured events and documentation, it's important to maintain regular communication, so I hope to start sending out newsletters on a monthly or bi-monthly schedule with general updates on what's been going on and what's coming up. The newsletters will also be published to runrig.org, as yet another form of documentation, for folks who are dropping by for the first time, or for those who prefer not to subscribe.</p><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>Examples may include Nextcloud for file sharing and storage (equivalent to Dropbox or Google Drive), NocoDB or Anytype as a low-code database/knowledge-base (Airtable, Notion, Obsidian), or Keycloak for identity and access management (Okta or Auth0). With time and concerted organizing, it may even become feasible to collectivize the kinds of cloud computing services dominated today by Amazon, Microsoft and Google, with FOSS alternatives like Ceph or Minio taking the place of Amazon S3 or Azure Blob as object storage services. After that there's the actual metal those services run on — the storage devices, networking hardware and server facilities — although I admit I'm getting way too far ahead of myself at that point. Importantly, however, even the smaller scale services like Nextcloud and Keycloak, while feasible to run on regional platform instances in <em>Phase Two</em>, will enjoy greater efficiencies by being managed on a global scale of the <em>Phase Three</em> data provider and provisioning resources out to the more <a href="https://www.runrig.org/posts/roadmap-2024.html#fnref1" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Runrig in 2025]]></title>
        <id>https://www.runrig.org/posts/runrig-in-2025.html</id>
        <link href="https://www.runrig.org/posts/runrig-in-2025.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2025-05-30T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Introducing the Runrig Journal, plus a recap of what's been going on with the project over the last year and a half.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Runrig in 2025</h1><p><strong>An overdue recap.</strong></p></header><div style="position:relative;" class="vp-doc _posts_runrig-in-2025" data-v-e6f2a212=""><div><p>It's been a while since I've posted a general update on Runrig. There are more details below on what's been going on with the project lately, but I also want to take this opportunity to address how I'll be shifting focus a bit going forward.</p><p>In brief, I've updated the <a href="https://www.runrig.org/journal.html">Runrig Journal</a> to accommodate a more consistent publication schedule for general articles, technical reports, and even the occasional long-form essay. I'll be starting off on a biweekly schedule, posting something new here on the website and sending it out in the <a href="https://buttondown.com/runrig" target="_blank" rel="noreferrer">newsletter</a>. I've also set up <a href="https://www.runrig.org/feed/rss.xml">RSS</a>, <a href="https://www.runrig.org/feed/atom.xml">Atom</a> &amp; <a href="https://www.runrig.org/feed/feed.json">JSON</a> feeds you can subscribe to; I took an <em>ad hoc</em>, "roll-your-own" approach to those feeds, so hopefully they all work! 🤞🏻</p><p>As a sample of the kind of material I intend to publish in the future, you can take a look at the essay I published last spring titled <a href="https://www.runrig.org/posts/hedgerows.html">"Hedgerows in the Sky"</a> or the documents I'm in the process of releasing as part of an ongoing consultation with the <a href="https://www.runrig.org/farm-flow.html">Farm Flow</a> app created by Fitzgerald Organics.</p><h2 id="what-s-been-going-on" tabindex="-1">What's Been Going On <a class="header-anchor" href="https://www.runrig.org/posts/runrig-in-2025.html#what-s-been-going-on" aria-label="Permalink to &quot;What's Been Going On&quot;">​</a></h2><p>Eighteen months ago, I laid out a <a href="https://www.runrig.org/posts/roadmap-2024.html">rather elaborate roadmap</a> for what I saw as the best path forward for Runrig in 2024. I felt it was time to narrow my focus on creating reference implementations that would showcase some of the untried strategies behind Runrig – to show rather than merely tell. This would be <em>Phase-Zero</em> in what I considered a <a href="https://www.runrig.org/posts/roadmap-2024.html#three-phase-organizing-model-or-business-plan">Three-Phase Organizing Model</a>. Though I specifically did not intend to pursue sponsorships or funding for that work, I saw it as the basis of an eventual business model for a tech-workers' cooperative.</p><p>Of course, putting such meticulous care into any sort of plan practically guarantees the universe will swat it down. That is more or less what happened when I was asked to consult on <a href="https://www.runrig.org/farm-flow.html">Farm Flow</a>. In many ways, it was the kind of project I'd have loved to take on in <em>Phase Two</em>, where I envisioned Runrig becoming a sort of "One-stop Platform Co-op Shop." By that I meant that we – and by then, it would surely have to be "we" and not just "I" – could be hired by farming communities or food cooperatives to setup service platforms customized for their region, so they retained full ownership and control while paying a small fee for managed hosting and light sysadmin work. Farm Flow wasn't a perfect 1-to-1 match for that sort of platform, but the more I learned the more I felt it could truly benefit by adapting some of those principles to its development. It seemed like too good an opportunity to pass up, to put some theory into practice and see how it measured up.</p><p>I've had the good fortune to participate in a few other projects and events over the past year, each working to shape, challenge, and reconfigure my conception of Runrig from what I first <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html">sketched out</a> roughly two years ago. Part of my intention with this reorganization of the website is to make <a href="https://www.runrig.org/plan.html">The Runrig Plan</a> more of a "living document" once again by enabling a more flexible publication format.</p><p>Around this time last spring, I was putting the finishing touches on a 6-month labor of love, which I titled <a href="https://www.runrig.org/posts/hedgerows.html">"Hedgerows in the Sky"</a> and published quietly here on the Runrig site, as well as on <a href="https://commonplace.knowledgefutures.org/pub/7m7brnr4/release/1" target="_blank" rel="noreferrer"><em>Commonplace</em></a> in abridged form. What started off as a belated reflection on the 2022 Gathering for Agricultural Technology (GOAT) had snowballed into a longer rumination on the relationship between agriculture and technology, enclosure and the commons, plus a bit of 18th century English folk poetry. You might call it an intellectual memoir of my own haphazard education in political economy, exploring such unwieldy concepts like <em>usufruct</em> and <em>alienation</em>; then combine that with a little amateur historiography, tracing the various ways <em>the commons</em> – both as a metaphor and as a practice – has shaped food and tech movements in North America since the end of the Cold War. I kept meaning to send a short newsletter regarding the essay, which never happened, but I was (and still am) quite pleased with how it turned out.</p><p>Later in August 2024, I carried those same ideas to <a href="https://dwebcamp.org" target="_blank" rel="noreferrer">DWeb Camp</a> in Navarro, CA, taking the main themes from "Hedgerows" as the point of departure for a panel discussion on appropriate technologies and non-extractive forms of sharing knowledge. As someone who rarely travels beyond the Northeastern U.S., the culture shock of Silicon Valley was acute, even in that remote park 2 hours north of the Bay, surrounded by tall redwoods and crunchy decentralized techno-hippies. But I mainly stuck to the "Cultivation Station," a square canopy that housed no more tha 40 people and where the agenda centered on food, ecology, free software, and tech justice. Under that tent in those short few days, I was quite gratified to meet a brilliant cohort of engineers, designers, and activists. Joining me on the panel were two familiar faces from my previous work with OpenTEAM and farmOS, Dr. Ankita Raturi from Purdue University's <a href="https://aginformaticslab.org/" target="_blank" rel="noreferrer">Axilab</a> and Tibet Sprague from <a href="https://www.hylo.com/" target="_blank" rel="noreferrer">Hylo</a>; there were also two new faces, Rudo Kemper, Program Director for <a href="https://conservationmetrics.com/" target="_blank" rel="noreferrer">Conservation Metrics</a> and Nadia Coelho Pontes, Co-founder of <a href="https://tekopora.top/" target="_blank" rel="noreferrer">Tekopora</a> in Brazil, who I was very pleased to meet for the first time on that panel. Really, everyone there was doing such phenomenal work; I hope I have a chance to reconnect with them all again and perhaps write a bit about their projects. There was also some vigorous debate around funding models for free &amp; open source software. I'm never short of opinions on that particular subject, so in the weeks after the conference I was compelled to draw some <a href="https://dweb.camp/p/foodweb__response-to-utility-proposal" target="_blank" rel="noreferrer">comparisons between Runrig's approach and other proposed methods</a>; I want to rework those slides, too, into something better suited for a general audience.</p><h2 id="on-deck" tabindex="-1">On Deck <a class="header-anchor" href="https://www.runrig.org/posts/runrig-in-2025.html#on-deck" aria-label="Permalink to &quot;On Deck&quot;">​</a></h2><p>I'm still processing so much of what I've learned and experienced over the last year, between Farm Flow, DWeb, my continuing involvement with GOAT and farmOS, and so forth. Those experiences have certainly left their mark on how I think about Runrig today and I've tried to express their implications in various places. I've committed a great deal of space in my personal journal, but also scattered about in various GitHub repositories, in emails with colleagues, in shared documents and slide presentations. Much of that material material is now enqueued for the Runrig Journal. As a little teaser, here's my working list of provisional titles:</p><ol><li>Runrig in 2025 [the present article]</li><li>Scaling &amp; Abstraction</li><li>Three Layers of Autonomy</li><li>Federated Autonomous Municipal Platforms</li><li>Intro to <a href="https://github.com/runrig-coop/runrig-farmos" target="_blank" rel="noreferrer">Runrig farmOS</a></li><li>Surmounting Local Maxima in the Fitness Landscape</li><li>Data Independence</li><li>Illegible Agriculture</li></ol><p>In addition, I'll be adding more information to the <a href="https://www.runrig.org/farm-flow.html">Farm Flow</a> project profile and creating similar profiles for <a href="https://github.com/runrig-coop/runrig-farmos" target="_blank" rel="noreferrer">Runrig farmOS</a> and the <a href="https://github.com/skywoman/multifarm-aggregation-info-arch" target="_blank" rel="noreferrer">MAIA Project</a>. Further on the horizon I still intend to return to <a href="https://github.com/runrig-coop/hedgerows/blob/main/notes/outline-of-narrative.md" target="_blank" rel="noreferrer">parts 2 &amp; 3 of "Hedgerows"</a> and a couple more ambitious concepts I've been mulling on, like "The Semiotics of Data" and "Socially Necessary Computation Time." So all you theory-nerds, stay tuned!</p><h2 id="the-future-of-runrig" tabindex="-1">The Future of Runrig <a class="header-anchor" href="https://www.runrig.org/posts/runrig-in-2025.html#the-future-of-runrig" aria-label="Permalink to &quot;The Future of Runrig&quot;">​</a></h2><p>In the course of developing these projects I've learned that perhaps the greatest challenge to realizing Runrig's full potential may lie in communicating its fundamental principles and methodology. From the very start, I've tried to downplay Runrig as any particular technology stack or software application, and instead emphasize the elements I hope can serve as a template for a very different <em>mode of producing</em> technology, regardless the final shape it takes. In other words, Runrig is meant to be more of a <em>social technology</em> than a digital technology, and so more analogous to the way Free &amp; Open Source Software (FOSS) functions as a manner of developing, say, the Linux kernel, rather than an analog to Linux itself. However, Runrig would go beyond free software principles, which I still view to be positively essential to producing good, ethical technology, but which I see as hampered by a narrowly liberal conception of freedom that only considers the individual. Runrig would strive to <em>socialize</em> the project for software freedom. As a radical new design methodology, you might compare Runrig to the Agile Manifesto or Lean Software Development, but diametrically opposed to those paradigms' deeply embedded, capitalistic assumptions about market-driven economics and infinite growth – or what technologists are so fond of calling <em>scalability</em>. Runrig would instead be an explicitly socialist methodology for distributing computational power, control, and ownership based on communalist principles.</p><p>The establishment of such a practice cannot be achieved merely through the implementation of one or another software program. As a social project, it first requires a quorum of participants and consensus on a shared set of values, and so those principles must be clearly stated, attested to, and argued for. I fully intend to continue developing software libraries and applications as a central part of this project, but I see their importance as secondary to the methods used to produce them. For those methods to have any meaningful impact, they must be communicated effectively, along with the rationale for employing them in the first place. If Runrig endures long enough to leave any sort of legacy behind, I'd like it to be the documentation of that methodology and the exposition of those principles. That will be the primary task of the <a href="https://www.runrig.org/journal.html">Runrig Journal</a> in the weeks ahead.</p><p>I still hope for Runrig to support a workers' cooperative in the future, too, so I'm always eager to speak with any other designers, engineers, or food workers who wish to contribute to the implementation and deployment of these kinds of services. Nothing would make me happier than to earn my livelihood with like-minded coworker-owners doing exactly that, maybe even something not too dissimilar from the kind of <a href="https://www.runrig.org/posts/roadmap-2024.html#three-phase-organizing-model-or-business-plan">co-op I described in the roadmap</a> a year and a half ago. At the same time, I've never assumed that it's Runrig's ultimate fate to become a going concern. With that in mind, I will be looking for ways to put Runrig into practice in my own community of New York City and the Hudson Valley region, ideally through mutual aid projects that I can benefit from directly, even if it's not in the form of a paycheck. So I doubly encourage anyone with an interest who also lives in the area to reach out as well. Of course, if you're someone who wants to support Runrig other ways, even if it's not as a dedicated co-op member or as someone in the Northeastern U.S., I'm sure not going to turn down help. And please forward this along to others who might like to get involved. Once I get the details for <a href="https://github.com/runrig-coop/runrig-farmos" target="_blank" rel="noreferrer">Runrig farmOS</a> organized on the site, I may look into ways of enabling sponsorship of specific projects as some form of crowdfunding initiative. In any event, if you've read this far and I've piqued your interest somehow, then by all means, please, <a href="mailto:jamie@runrig.org" target="_blank" rel="noreferrer">don't be a stranger!</a></p></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Appendix: Architecture]]></title>
        <id>https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html</id>
        <link href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2023-04-16T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Unfinished draft note of Runrig's architectural features.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Appendix: Architecture</h1></header><div style="position:relative;" class="vp-doc _posts_the-runrig-plan-appendix-architecture" data-v-e6f2a212=""><div><div class="warning custom-block"><p class="custom-block-title">ARCHIVED</p><p>Unfinished draft note of Runrig's architectural features.</p></div><h2 id="system-characteristics" tabindex="-1">System Characteristics <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#system-characteristics" aria-label="Permalink to &quot;System Characteristics&quot;">​</a></h2><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>The main points here warrant further evaluation and debate, to be sure, but eventually it would be nice to represent the agreed-upon system characteristics in a tabular format, preferably somewhere at the top of this appendix, while the details and citations should be integrated into the body text, across the relevant page sections.</p></div><ul><li>End-to-end semantics <ul><li>Lawrence Lessig's 2001 Frey Lecture at Duke University, <a href="https://scholarship.law.duke.edu/dlj/vol51/iss6/2/" target="_blank" rel="noreferrer">"The Architecture of Innovation"</a></li></ul></li><li>Design for autonomy across the entire stack <ul><li>Andre Staltz: <a href="https://staltz.com/a-plan-to-rescue-the-web-from-the-internet.html" target="_blank" rel="noreferrer">"A Plan to Rescue the Web from the Internet"</a> and <a href="https://www.youtube.com/watch?v=izQFMADw70w&amp;t=560s" target="_blank" rel="noreferrer">"The Decentralized Web" (video)</a><ul><li>We've hard-coded the Internet's stack (TCP, IPv4, HTTP, etc)</li><li>Rebuild the OSI Model with new protocols (Dat/Hypercore, IPFS, etc)</li></ul></li><li>Bluesky's <a href="https://gitlab.com/bluesky-community1/decentralized-ecosystem/-/blob/ab63b57f13ddea7f4adacf041d3f8c392c73bfdb/README.md" target="_blank" rel="noreferrer">"Decentralized Ecosystem: Overview"</a></li><li>Rich Hickey's 2012 Clojure/Conj talk, <a href="https://github.com/matthiasn/talk-transcripts/blob/d644becd0f4eebb3a165a63b3bdf1e8d6b881d33/Hickey_Rich/LanguageSystem.md" target="_blank" rel="noreferrer">"The Language of the System"</a><ul><li>Application Stack vs. System Stack</li><li>Protocols (eg, TCP, UDP, HTTP, Web Sockets, etc) as the language primitives for the entire system</li><li>Self-describing data formats with <em>in-band</em> schema definitions (XML, Avro, EDN), also as system primitives</li><li>Simple System Services (eg, Redis, S3, Riak, Apache Storm &amp; ZooKeeper) as the core or standard libraries and runtime for the system</li></ul></li></ul></li><li>Data Independence: "a clear separation is enforced between the logical data and its physical representation" (Moseley &amp; Marks) <ul><li>E.F. Codd, <a href="https://dl.acm.org/doi/10.1145/362384.362685" target="_blank" rel="noreferrer">"A relational model of data for large shared data banks"</a></li><li>C.J. Date, <a href="https://archive.org/details/introductiontoda0000date" target="_blank" rel="noreferrer"><em>An Introduction to Database Systems (8th Edition)</em></a><ul><li><a href="https://archive.org/details/introductiontoda0000date/page/n53/mode/2up" target="_blank" rel="noreferrer">§1.5 "Data Independence"</a></li></ul></li><li>Ben Moseley and Peter Marks, <a href="https://www.recurse.com/blog/51-paper-of-the-week-out-of-the-tar-pit" target="_blank" rel="noreferrer">"Out of the Tarpit"</a>, §8 "The Relational Model": <ul><li><blockquote><p>The relational model [Cod70] has — despite its origins — nothing intrinsically to do with databases. Rather it is an elegant approach to structuring data, a means for manipulating such data, and a mechanism for maintaining integrity and consistency of state. These features are applicable to state and data in any context.</p></blockquote></li></ul></li><li>Patricia Sellinger, et al., <a href="https://dl.acm.org/doi/10.1145/582095.582099" target="_blank" rel="noreferrer">"Access path selection in a relational database management system"</a></li><li>Mark Levene, <a href="https://archive.org/details/nesteduniversalr0595leve" target="_blank" rel="noreferrer">"The Nested Universal Relation Database Model"</a><ul><li><a href="https://archive.org/details/nesteduniversalr0595leve/page/1/mode/2up" target="_blank" rel="noreferrer">§1.1 "Background and Motivation"</a></li><li><a href="https://archive.org/details/nesteduniversalr0595leve/page/29/mode/2up" target="_blank" rel="noreferrer">§2.3 "The Universal Relation Model"</a></li></ul></li></ul></li></ul><h2 id="data-provider" tabindex="-1">Data Provider <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#data-provider" aria-label="Permalink to &quot;Data Provider&quot;">​</a></h2><h3 id="storage-provisioning" tabindex="-1">Storage Provisioning <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#storage-provisioning" aria-label="Permalink to &quot;Storage Provisioning&quot;">​</a></h3><p>It may also be helpful to structure storage costs in a way that a platform or service on a platform can provision a block of storage for multiple users on a Solid server, so they can build that cost into their own fees and/or shared costs.</p><p>This is actually quite similar to how the private Solid provider, use.id, designs their Provisioning API:<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#fn1" id="fnref1">[1]</a></sup> <sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#fn2" id="fnref2">[2]</a></sup></p><div class="language-http vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">http</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># </span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">@name</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> provisioning</span></span>
<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">#</span></span>
<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># Registers a new WebID, if it does not already exist, and creates a new WebID profile for it.</span></span>
<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># Value for Slug is used for creating the WebID -- here: https://dev.use.id/tom</span></span>
<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">#</span></span>
<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># Responds with 201 Created, a Location header to the new WebID, and the contents of the WebID profile as a body.</span></span>
<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># Responds with 409 Conflict if the WebID already exists.</span></span>
<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">#</span></span>
<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">POST</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> /provision </span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">HTTP</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">/</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">1.1</span></span>
<span class="line"><span style="--shiki-light:#22863A;--shiki-dark:#85E89D;">Host</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> https://dev.use.id</span></span>
<span class="line"><span style="--shiki-light:#22863A;--shiki-dark:#85E89D;">Authorization</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> DPoP &lt;api-token&gt;</span></span>
<span class="line"><span style="--shiki-light:#22863A;--shiki-dark:#85E89D;">DPoP</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &lt;dpop-proof&gt;</span></span>
<span class="line"><span style="--shiki-light:#22863A;--shiki-dark:#85E89D;">Content-Type</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> application/json</span></span>
<span class="line"><span style="--shiki-light:#22863A;--shiki-dark:#85E89D;">Slug</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">:</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> tom</span></span>
<span class="line"></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">{</span></span>
<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">    "email"</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">: </span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">"tom-stevens@email.com"</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">    "password"</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">: </span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">"passwd1234"</span></span>
<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><p>other considerations...</p><ul><li>one person, one pod?</li><li>use of homomorphic encryption and synthetic data?</li><li>auth flows</li></ul><h3 id="why-solid" tabindex="-1">Why Solid? <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#why-solid" aria-label="Permalink to &quot;Why Solid?&quot;">​</a></h3><p>As described in Solid Project's documentation:</p><blockquote><p>One of the core ideas behind Solid is to make <strong>data</strong> independent from <strong>applications</strong>, so that one can be in control of his/her own data and share it with the apps of his/her choice. For this to be possible, the same piece of data must be understood <strong>consistently</strong> from one app to another. This requires agreeing on the meaning of the data, as conveyed by its description. Therefore, to make data reusable, it should be described with vocabularies that are widely used and known.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#fn3" id="fnref3">[3]</a></sup></p></blockquote><h2 id="service-platforms" tabindex="-1">Service Platforms <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#service-platforms" aria-label="Permalink to &quot;Service Platforms&quot;">​</a></h2><h3 id="distributed-federated-services-applications" tabindex="-1">Distributed, Federated Services &amp; Applications <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#distributed-federated-services-applications" aria-label="Permalink to &quot;Distributed, Federated Services &amp; Applications&quot;">​</a></h3><p>When it comes to hosting services and applications, I think it makes sense to host and operate that software on a smaller, regional scale and in a more distributed manner, compared to how data for that software will be hosted and stored. This is the second of the "primary responsibilities" listed above.</p><p>Mostly, this will be done to allow greater localized control of the actual applications and services they host, which may require additional storage for more sensitive information like billing, payments and personnel data. They should also be empowered to modify and extend their software as befits their particular needs. Likewise, they should be granted a high level of local autonomy in determining how costs are shared, how prices are set, and how the overall governance of their regional platform is administered. However, they will still benefit from services and resources that are shared nationally and globally, such as Solid pod storage. By the same token, they will also be obliged to contribute finances or resources globally and abide by the terms set by those broader governing bodies, though ideally any restrictions would be kept minimal and enforcement rarely called for in practice.</p><p>It might be helpful to illustrate this with a stack diagram, like the ones used for illustrating architecture of the Linux kernel and similar technology systems:</p><p><img src="https://upload.wikimedia.org/wikipedia/commons/9/99/Linux_kernel_and_OpenGL_video_games.svg" alt="Stack diagram of the Linux
kernel"></p><h2 id="references" tabindex="-1">References <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#references" aria-label="Permalink to &quot;References&quot;">​</a></h2><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>use.id. <a href="https://get.use.id/business" target="_blank" rel="noreferrer">"use.id for Business"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#fnref1" class="footnote-backref">↩︎</a></p></li><li id="fn2" class="footnote-item"><p>Van den Briel, Abel. <em>use.id Forum</em>. <a href="https://forum.use.id/t/design-of-the-provisioning-api-feedback-welcome/40" target="_blank" rel="noreferrer">"Design of the Provisioning API - Feedback welcome"</a> (login required). Jan 31, 2022. Further in that forum post it states that "<code>&lt;api-token&gt;</code> is an access token, retrieved from the <a href="https://forum.use.id/t/how-to-access-use-ids-api-with-your-apps-webid/62" target="_blank" rel="noreferrer">client credentials flow</a>" and that "<a href="https://forum.use.id/t/how-to-create-a-dpop-proof-header/63" target="_blank" rel="noreferrer"><code>&lt;dpop-proof&gt;</code></a> is unique per request". Another commenter, identified as use.id staff, cautions that sending passwords is not intended for production use and is only provided as a temporary example while passwordless flow is still being implemented, but as of April 2022, that system was not ready for testing. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#fnref2" class="footnote-backref">↩︎</a></p></li><li id="fn3" class="footnote-item"><p>Solid Project. <a href="https://solidproject.org/developers/vocabularies" target="_blank" rel="noreferrer">"Vocabularies overview"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html#fnref3" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Appendix: Ecology]]></title>
        <id>https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html</id>
        <link href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2023-04-16T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Unfinished draft note of Runrig's social, economic, and ecological design principles.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Appendix: Ecology</h1></header><div style="position:relative;" class="vp-doc _posts_the-runrig-plan-appendix-ecology" data-v-e6f2a212=""><div><div class="warning custom-block"><p class="custom-block-title">ARCHIVED</p><p>Unfinished draft note of Runrig's social, economic, and ecological design principles.</p></div><h2 id="reframing-production-consumption-as-metabolic-exchange" tabindex="-1">Reframing Production &amp; Consumption as Metabolic Exchange <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#reframing-production-consumption-as-metabolic-exchange" aria-label="Permalink to &quot;Reframing Production &amp; Consumption as Metabolic Exchange&quot;">​</a></h2><p>As we first addressed in the <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html">"Overview"</a> and will further detail in <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html">"Appendix: Architecture"</a>, Runrig makes certain architectural and design choices in order to accommodate complexity while distributing the costs incrementally over time and across a greater number of stakeholders. But it cannot achieve those ends by architecture alone, as the motto <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#ecology-over-architecture">"ecology over architecture"</a> is meant to convey. Loosely speaking, the ecology we refer to here includes the various social and biotic relations that comprise a food shed. Put another way, it is the total process undergone by the constituents of that food shed whereby their shared energy and material move throughout the system, abiding by those relations. Rather than alternately producing and consuming, as a commodities market would, <em>an ecology always and only ever metabolizes</em>.</p><p>For the purposes of this document, we will consider ecology by means of three approximations:</p><ul><li>Economic Models &amp; Planning</li><li>Legal Rights &amp; Agreements</li><li>Community Governance &amp; Methodology</li></ul><p>These can only serve as crude standbys for the full dynamic range of a functioning ecology, but we hope even the staunchest dollars-and-cents pragmatist can appreciate their need for attention.</p><h2 id="economic-models-planning" tabindex="-1">Economic Models &amp; Planning <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#economic-models-planning" aria-label="Permalink to &quot;Economic Models &amp; Planning&quot;">​</a></h2><h3 id="the-core-challenge" tabindex="-1">The Core Challenge <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#the-core-challenge" aria-label="Permalink to &quot;The Core Challenge&quot;">​</a></h3><p>Prior to the launch of Skywoman's MAIA Project, I argued it's not only preferable to build farm software by open and cooperative methods, but if we are sincere in our intentions to aid food sovereignty with appropriate technologies, then private startups and more traditional business models are wholly insufficient to the task:</p><blockquote><p>I truly believe that the development of such resilient systems is something that can only be achieved through a radically cooperative enterprise. The data underpinning the networks of agricultural production and food distribution is so inextricably complex; it is no accident that this complexity only skyrockets when due respect and full equity is granted to every person and creature involved, as well as the land and overall ecology that contributes to feeding a community. It is a reflection of the social and cultural complexities underpinning how we eat, grow and relate to one another and our environment. I don't think there can be a just and equitable software system, capable of handling all that informational complexity, if it doesn't have social and ecological cooperation baked right into the design and methodology of the system itself.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fn1" id="fnref1">[1]</a></sup></p></blockquote><p>But software costs money. While we should reject the narrow view that dollars and cents are all that matter here, we still need to acknowledge that certain economic barriers must be surmounted if we wish to take any of this beyond mere theory. Specifically, software development requires compensating engineers and designers, who can otherwise fetch 6-figure salaries or more for their expertise.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fn2" id="fnref2">[2]</a></sup> That can drive costs quite high, and rather quickly too. As much as we seek to conserve the essential complexity of the natural systems our software hopes to model, as software complexity increases, those costs can truly explode.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fn3" id="fnref3">[3]</a></sup> Tremendous experience is required just to reliably estimate the final costs of an extended, complex project, let alone to keep everything on budget all the way to completion.</p><p>Being familiar with these realities from both the farmer's and the engineer's side of the table, Chris Newman addresses the complaint of a another farmer who has worked first-hand with proprietary software companies. They relate a common experience where the "solutions experts" insinuated that the complexity of the farm's operation was itself to blame for the failure of the software to meet the farm's needs. As he writes,</p><blockquote><p>Software companies are not in the food business, they don't have any business telling you how to run yours, and if they do, they're deliberately attempting to throttle what works for you in order to make you work for them.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fn4" id="fnref4">[4]</a></sup></p></blockquote><p>One could interpret this as venture capital imposing <em>legibility</em> upon the social and ecological diversity of a community, to borrow an anarchist turn of phrase,<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fn5" id="fnref5">[5]</a></sup> or what Marxists would term <em>commodity fetishism</em>.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fn6" id="fnref6">[6]</a></sup> The compulsion to simplify their operations is not meant to facilitate the existing ways a community farms and feeds itself, in accordance to its own cultural and environmental concerns; it is meant to render the labor, knowledge and matériel of that community more suitable for mass consumption and capital accumulation. Any costs associated with adapting inherently complex natural and social systems to simpler commodity forms, ready for consumption, are of course deflected onto the community itself, rather than investors.</p><p>The core challenge, however, still remains: how can diverse food communities bring their full capacities to bear upon the creation of free and appropriate technologies that meet their material needs and reflect their collective values? More to the point, how do we manage all the associated costs? While we strive to avoid further exploitation by private software platforms, we continue to live under the artificial scarcities of capitalism, so how do we manage what scarce resources we have left — amidst all other competing demands on them — to sustain communally owned software alternatives?</p><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>This rest of this section is still in draft. Provisional outline:</p><ul><li>Funding etc...</li><li>Sliding-scale hosting &amp; services</li><li>Storage provisioning</li></ul></div><h3 id="class-struggle-cooperativism" tabindex="-1">Class Struggle Cooperativism <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#class-struggle-cooperativism" aria-label="Permalink to &quot;Class Struggle Cooperativism&quot;">​</a></h3><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>It may be good to refer to these principles here or elsewhere in the Runrig Plan.</p></div><p>In Cooperation Jackson's May 1, 2023 article, <a href="https://cooperationjackson.org/announcementsblog/buildingclassconsciouscoops" target="_blank" rel="noreferrer">"Building Class Conscious Cooperatives"</a>, Kali Akuno lays out five "Basic Principles of Class Struggle or Class Conscious Cooperatives":</p><blockquote><ol><li>Serving as instruments of working class self-organization, with the aim and objective of enabling the working class to own and control the fundamental means of production to enable the democratization of society and the regeneration of the earth’s ecosystems through coordinated planning to produce the use-value oriented instruments and necessities needed to improve the overall quality of life of the vast majority of the earth’s inhabitants within the ecological and material limitations of our precious planet.</li><li>Engaging in active solidarity with other workers, worker formations, and workers self-organizing campaigns and initiatives towards the objectives of helping them become self-directed, democratic institutions committed to the socialization of production, the democratization of society, and the regeneration of the earth’s ecosystems.</li><li>Demonstrating the principle of non-competition with and between other workers. We need to be clear that when and where we compete has to be directed against capital and its representatives to deliberately break capital’s domination over the means of production and the relations of production. On a practical level, this type of competition must entail supporting the organizing initiatives of the workers in the firms we are struggling against to help them unionize and take over the enterprise and turn it into a worker cooperative. These worker cooperatives must be willing and able to become social production enterprises willing to engage in participatory planning processes to manage the economy.</li><li>Encouraging all existing unions, worker centers, and other worker formations to organize themselves to seize (socialize) the means of production by converting their workplaces into cooperatives or commons or social based sites of production, and support them with training materials, resource mobilization, mutual aid, consultative advice, and strategic deployment when and where necessary.</li><li>Organizing the un and under organized sectors of the working class, who constitute the vast majority of the class, particularly in the US, into vehicles of self organization that best fit their local conditions and enable them to engage successfully in the class struggle at every progressive stage of our development and scale of deployment.</li></ol></blockquote><h2 id="legal-rights-agreements" tabindex="-1">Legal Rights &amp; Agreements <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#legal-rights-agreements" aria-label="Permalink to &quot;Legal Rights &amp; Agreements&quot;">​</a></h2><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>This section is entirely in draft and comprised mostly of notes. Provisional outline:</p><ul><li>Intellectual Usufruct Rights</li><li>Service-level agreements</li><li>Copyfair licensing</li><li>Fiduciary obligations</li><li>Grant/revoke proxy rights</li><li>Broader juridico-political issues <ul><li>from the <a href="https://blog.ldodds.com/2017/03/24/what-is-data-asymmetry/" target="_blank" rel="noreferrer">data asymmetries</a> exploited by Big Tech to the <a href="https://www.nobelprize.org/prizes/economic-sciences/2001/popular-information/" target="_blank" rel="noreferrer">asymmetric information</a> leveraged by global finance</li><li>the efficacy of contract law and legislative reform vs. direct action and more militant tactics</li></ul></li></ul></div><h3 id="main-legal-entities-constituting-the-runrig-system" tabindex="-1">Main Legal Entities Constituting the Runrig System <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#main-legal-entities-constituting-the-runrig-system" aria-label="Permalink to &quot;Main Legal Entities Constituting the Runrig System&quot;">​</a></h3><ol><li>A <strong>data cooperative</strong> or <strong>data trust</strong>, likely incorporated as a non-profit, whose members are users of the global data provider. They can join through a service platform authorized to provision that storage on the user's behalf, or by directly provisioning space on the data provider themselves. The data coop will have legal custody of the data provider's main servers, but may contract the administration and maintenance of those servers to the worker coop (described in #2 below). It may also hold the licenses to Runrig's core software modules, trademarks, etc., though that could also be delegated to a conservancy, such as the Software Freedom Conservancy or the Commons Conservancy.</li><li>A <strong>worker cooperative</strong> of engineers, designers and system administrators, responsible for the main data provider and core services, under contract to the data cooperative. It is also responsible for maintaining the free libraries, API's and other integrations used by the service platforms, possibly even the application software they use. They are also available on contract to develop custom, sponsored software at the request of one or several service platforms (ideally those solutions will nevertheless be contributed back to the commons and made free to all, not just the sponsoring platform). Hosting and other backend services could also be provided to the service platforms at preferred rates. In the beginning this may be more loosely structured as more of a freelancer's coop, while there may not be much in the way of significant revenues to sustain fulltime worker-owners.</li><li><strong>Service platform cooperatives</strong>, situated in regional foodsheds and serving more localized needs, which may vary widely in scope, purpose and membership. The specifics will be more up to the constituents of those platforms themselves, but there should be some criteria for what platforms are permitted to join the data provider and provision storage on behalf of its users. It is conceivable that they need not be a cooperative, strictly speaking, but it may be desireable place some restrictions on non-cooperative for-profit business, while also including some kind of statement of shared values in any agreements, and possibly provide discounts or other incentives to coops and non-profits.</li></ol><h3 id="membership-classes" tabindex="-1">Membership Classes <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#membership-classes" aria-label="Permalink to &quot;Membership Classes&quot;">​</a></h3><ol><li><strong>Data Members:</strong> Individuals, farms, collectives or traditional companies who have some amount of their own data stored on the data provider, via a service platform(s) or with a direct membership account. The set of data members should be coterminous with the set of storage user accounts.</li><li><strong>Service Members:</strong> Platform coops and other service platforms who can join the data cooperative with the right to broker agreements with data members and provision storage for them on the data provider, granting them status of data members in the process. Note that service membership is distinct from any form of membership that entities might hold with a service platform itself, for those platforms which confer any form of membership status; such status is managed by the platforms and not with the purview of the Runrig system. It may be possible, however, for an entity to hold dual membership as both a service member and a data member. if a service member wishes to have storage on the data provider, separate from its constituent userss.</li><li><strong>Worker Members:</strong> Engineers, designers, etc who develop and maintain the software and underlying infrastructure. Unlike the other membership classes, these are members of separate worker cooperative, not the data cooperative.</li><li><strong>Community Members:</strong> Trusted supporters and advisors from the community, who may wish to participate in member assemblies and activities, but no voting rights or other privileges, so more symbolic than anything else.</li></ol><h3 id="service-level-agreements" tabindex="-1">Service-level Agreements <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#service-level-agreements" aria-label="Permalink to &quot;Service-level Agreements&quot;">​</a></h3><p>All of this necessitates that care is taken when drafting the terms of service and other service-level agreements, both between storage providers and regional platforms, and between regional platforms and individual users.</p><h4 id="transferral-of-rights-responsibilities" tabindex="-1">Transferral of Rights &amp; Responsibilities <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#transferral-of-rights-responsibilities" aria-label="Permalink to &quot;Transferral of Rights &amp; Responsibilities&quot;">​</a></h4><p>There are some potential issues when it comes to how storage and access rights, payment accounts and other privileges and obligations can be transferred between parties of various membership classes.</p><p>For instance, let's say a user joins the data coop through a service platform that pays a significant amount for that user's storage space and access on the data provider (for instance, for hi-res satellite imagery or other large media files). What happens when the user decides to leave the service platform?</p><p>There are many ways to go about this, but some possible options that could be given to the user at that time:</p><ul><li>Export and delete their data from the data provider.</li><li>Transfer of payment authorization to another service or to the data coop itself, which could continue billing the user without any interruption of service or costly migrations.</li><li>Offer free storage and access of their data in exchange for contributing it to the public domain, or participating in an anonymized public research project, with costs to the data coop offset by relevant research funding.</li><li>Set up an application for "solidarity credits" to host a certain storage limit for a given period of time for reduced cost or free of charge.</li></ul><h3 id="informational-usufruct-rights" tabindex="-1">Informational Usufruct Rights <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#informational-usufruct-rights" aria-label="Permalink to &quot;Informational Usufruct Rights&quot;">​</a></h3><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>These are some loose thoughts that first came up at the <a href="https://forum.goatech.org/t/session-data-policy/1294" target="_blank" rel="noreferrer">GOAT 2022 session on Data Policy</a> but still need to be refined.</p></div><p>There is a prevalent yet false impression about data, that it is a form of intellectual property, and that ownership or certain legal entitlements pertain to data the same way they do to creative works, software and real property. Feist v Rural Telephone, GDPR, etc, etc.</p><p>Can <strong>intellectual property rights</strong> be reframed as <strong>informational <a href="https://en.wikipedia.org/wiki/Usufruct" target="_blank" rel="noreferrer">usufruct</a> rights</strong>? Such rights can then be governed in terms of who is granted access (<em>usus</em>) to that information, which can constitute either a creative work or data set, as well as its derivatives (<em>fructus</em>); however, exclusive rights to <a href="https://en.wikipedia.org/wiki/Alienation_(property_law)" target="_blank" rel="noreferrer">alienation</a> (<em>abusus</em>) will be rejected, except in the case of <a href="https://gdpr-info.eu/art-4-gdpr/" target="_blank" rel="noreferrer">personal data as defined by the GDPR</a>. Care should also be given to ensure that all rightsholders enjoy an equal capability to make full use of such information as they please.</p><h4 id="ejidos-digitales" tabindex="-1"><em>Ejidos digitales</em> <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#ejidos-digitales" aria-label="Permalink to &quot;_Ejidos digitales_&quot;">​</a></h4><p>...like water rights, but for the flow of data; or collective land management, but for network infrastructure and compute resources.</p><h3 id="data-cooperatives-fiduciary-obligations" tabindex="-1">Data Cooperatives &amp; Fiduciary Obligations <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#data-cooperatives-fiduciary-obligations" aria-label="Permalink to &quot;Data Cooperatives &amp; Fiduciary Obligations&quot;">​</a></h3><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>These are taken straight from an earlier set of personal notes, and so need to be rewritten entirely. And while the legal aspect of fiduciary agreements should be discussed here, the specifics of data coop governance should probably wait until the next section.</p></div><p>In <a href="https://coop.exchange/blog/430124ff-621a-11ea-b711-06ceb0bf34bd/data-co-ops-4-examples-and-new-ideas" target="_blank" rel="noreferrer">an article</a> from Coop Exchange about data coops, they describe the <a href="https://driversseat.co/" target="_blank" rel="noreferrer">Driver's Seat Cooperative</a>'s mission:</p><blockquote><p>Drivers Seat Data Cooperative allows drivers using platforms like Uber or Lyft to track their driving and pay to figure out the optimal times to make money based on their schedule, where they should drive when it is slow, etc. They can choose to share the data with city agencies to help with transportation planning. The drivers own the cooperative and it enables them to get more money for work they are already doing.</p></blockquote><p>This got me to think again about the whole concept, especially as it relates to <a href="https://regenfarmersmutual.com/" target="_blank" rel="noreferrer">Regen Farmers Mutual</a>. Looking on <a href="https://en.wikipedia.org/wiki/Data_cooperative" target="_blank" rel="noreferrer">the Wikipedia page</a>, it had a great little diagram:</p><p><img src="https://upload.wikimedia.org/wikipedia/commons/4/42/Data_Cooperative_Key_Aspects_2.0.png" alt="Data Cooperative Key
Aspects"> Follwing some references from the same Wikipedia article, I found a couple of good scholarly articles. Chief among them, <a href="https://arxiv.org/abs/1905.08819" target="_blank" rel="noreferrer">"Data Cooperatives: Towards a Foundation for Decentralized Personal Data Management"</a> by Thomas Hardjono and Alex Pentland is most pertinent to the fiduciary obligations of data coops specifically, as the abstract indicates:</p><blockquote><p>Data cooperatives with fiduciary obligations to members provide a promising direction for the empowerment of individuals through their own personal data. A data cooperative can manage, curate and protect access to the personal data of citizen members. Furthermore, the data cooperative can run internal analytics in order to obtain insights regarding the well-being of its members. Armed with these insights, the data cooperative would be in a good position to negotiate better services and discounts for its members. Credit Unions and similar institutions can provide a suitable realization of data cooperatives.</p></blockquote><p>The article even goes into some specifics on the technical architecture and how to use the MIT "Open Algorithms" paradigm (abbreviated as OPAL) in the implementation of data coops. The authors, together with Alexander Lipton, are also the authors of <a href="https://wip.mitpress.mit.edu/new-economy" target="_blank" rel="noreferrer"><em>Building the New Economy: Data as Capital</em></a>. In this article, however, they give a concise description of 3 "key aspects" of data coops, which I believe is the source of the diagram above:</p><blockquote><ul><li><p><em>Individual members own and control their personal data</em>: The individual as a <em>member</em> of the data cooperative has unambiguous legal ownership of (the copies of) their data. Each member can collect copies of their data through various means, either automatically using electronic means (e.g. passive data-traffic copying software on their devices) or by manually uploading data files to the cooperative. This data is collected into the member’s personal data store (PDS) [3]. The member is able to add, subtract or remove data from their personal data store, and even suspend access to their data store. A member may posses multiple personal data repositories.</p><p>The member has the option to maintain their personal data store at the cooperative, or host it elsewhere (e.g. private data server, cloud provider, etc). In the case where the member chooses to host the personal data store at the cooperative, the cooperative has the task of protecting the data (e.g. encryption for data loss prevention) and optionally curating the data sets for the benefit of the member (e.g. placing into common format, providing informative graphical reporting, etc.).</p></li><li><p><em>Fiduciary obligations to members</em>: The data cooperative has a legal fiduciary obligation first and foremost to its members. The organization is member-owned and member-run, and it must be governed by rules (bylaws) agreed to by all the members.</p><p>A key part of this governance rules is to establish clear policies regarding the usage or access to data belonging to its members. These policies have direct influence on the work-flow of data access within the cooperative’s infrastructure, which in turn has impact on how data privacy is enforced within the organization.</p></li><li><p><em>Direct benefit to members</em>: The goal of the data cooperative is to benefit its members first and foremost. The goal is not to “monetize” their data, but instead to perform on-going analytics to understand better the needs of the members and to share insights among the members.</p></li></ul></blockquote><p>The references section is also a goldmine, with several other articles by the same authors. Also among those references is a pretty good article from UC Davis on the legal aspects of information fiduciaries in general, coops or not, titled <a href="https://lawreview.law.ucdavis.edu/issues/49/4/Lecture/49-4_Balkin.pdf" target="_blank" rel="noreferrer">"Information Fiduciaries and the First Amendment"</a>.</p><h2 id="community-governance-methodology" tabindex="-1">Community Governance &amp; Methodology <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#community-governance-methodology" aria-label="Permalink to &quot;Community Governance &amp; Methodology&quot;">​</a></h2><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>This is just a placeholder for a section that needs drafting. Provisional outline:</p><ul><li>Data cooperatives (split this out from the fiduciary discussion above?)</li><li>Distribution of voting shares</li><li>Standards &amp; Tools (might delete)</li></ul><p>Follow-up on this research on data governance by UK non-profit Nesta, via Muldoon:</p><ul><li>Mulgan, Geoff and Vincent Straub. <a href="https://www.nesta.org.uk/blog/new-ecosystem-trust/" target="_blank" rel="noreferrer">"The new ecosystem of trust"</a>, <em>Nesta</em>, 21 February 2019.</li><li>Borkin, Simon. <a href="https://media.nesta.org.uk/documents/Nesta_Platform_Report_FINAL-WEB_b1qZGj7.pdf" target="_blank" rel="noreferrer">"Platform co-operatives – solving the capital conundrum"</a>, <em>Nesta</em>, February 2019.</li><li>Bass, Theo and Rosalyn Old, <a href="https://media.nesta.org.uk/documents/DECODE_Common_Knowledge_Citizen_led_data_governance_for_better_cities_Jan_2020.pdf" target="_blank" rel="noreferrer">"Common Knowledge: Citizen-Led Data Governance for Better Cities"</a>, <em>Nesta</em>, January 2020.</li></ul></div><h3 id="standards-and-tools" tabindex="-1">Standards and Tools <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#standards-and-tools" aria-label="Permalink to &quot;Standards and Tools&quot;">​</a></h3><div class="warning custom-block"><p class="custom-block-title">DRAFT NOTE</p><p>Much of this section seems like a poorly focused rehashing of the "Economic Challenges" above. Most of it can probably be scrapped, but see what portions actually pertain to governance &amp; methodology and could be salvaged.</p></div><p>We've come to believe what we're told about data standards and shared ontologies: that they are great in theory, but in the real world things are too complex and you either end up having a standard that's too specific and opinionated that it doesn't work for everyone, or too broad and generalized that it's just not very useful. The Semantic Web itself has endured a great deal of criticism along these lines over it's 20-year history.</p><p><img src="https://imgs.xkcd.com/comics/standards.png" alt="standards"></p><p>But the unspoken assumption here is that those standards have to survive "trial by market", where the kind of close coordination required to produce and maintain a practicable, living standard is all but prohibited by the profit-seeking, competitive demands of the market. Even as proprietary software giants like Microsoft and Oracle become cozier with open source technologies and a general appreciation of the "commons" pervades the industry, control of the actual data and services generated by those open source tools remains heavily restricted and privatized. After all, without the privatized control of some utility or the enclosure of some asset, where would the capital accumulation come from?</p><p>Attempts to take back ownership and control of "Software-as-a-Service" have largely struggled, I would argue, because we've sought too narrowly to redistribute those rights piecemeal to individual users, rather than seeking <em>common ownership</em>. Certainly, there are great benefits to individual control in many contexts, but we handicap our projects by limiting ourselves to those alternatives exclusively. Taken to the extreme, this would necessitate everyone have their own server rack in the garage (or at least a Raspberry Pi in the closet), each of us rolling our own servers independently from one another.</p><p>My fear, however, is that if we're too predisposed to self-hosting, we will needlessly alienate people who may not want to use a particular piece of software or hardware, but may wish to participate in the social and economic activities that such software and hardware facilitate. We would do well to regard Ivan Illich's criteria for "convivial" tools:</p><blockquote><p>Tools foster conviviality to the extent to which they can be easily used, by anybody, as often or as seldom as desired, for the accomplishment of a purpose chosen by the user. The use of such tools by one person does not restrain another from using them equally. They do not require previous certification of the user. Their existence does not impose any obligation to use them. They allow the user to express his meaning in action. (22)</p></blockquote><p>While promising new paradigms like software "appliances"<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fn7" id="fnref7">[7]</a></sup> might eventually offer the option of plug-and-play personal servers, achieving both autonomous <em>and ubiquitous</em> computing in the same stroke, they would still leave critical issues unaddressed. The data and computing capabilities of several billion humans are today at the whim of just a few dozen technocratic billionaires. Any serious challenge to these proprietary platforms, and all the coercive force at their disposal, must come from a base of organized, community-driven political power, built around shared resources. Now is not the time to retreat into isolation, each of us behind our own firewall.</p><p>Common ownership of our platforms is a far more effective means towards that end, but also an end in itself...</p><h2 id="references" tabindex="-1">References <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#references" aria-label="Permalink to &quot;References&quot;">​</a></h2><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>Gaehring, Jamie. <a href="https://jgaehring.com/blog/platform-coop" target="_blank" rel="noreferrer">"Toward a Platform Cooperative for Food Sovereignty"</a>. August 05, 2022. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fnref1" class="footnote-backref">↩︎</a></p></li><li id="fn2" class="footnote-item"><p>Bound up in the problem of software costs is the ill-founded distinction between skilled and unskilled labor, and it must be addressed when considering an industry like agriculture where wages are routinely stolen and rarely meet the standard of a true living wage. We should aim to counteract such tendencies as much as possible through transparent pay scales, explicit limits on compensation, and other measures, even if that means less competitive salary offerings for technical workers. However, discretion should always be applied here. Tech workers will and ought to be mindful of the opportunity costs associated with accepting a lower paying position, even if they see the higher purpose, while also weighing that with any educational debt they may have accrued, or how their salary history may effect future offerings. It should never be incumbent upon these workers alone to fix the societal error of assigning higher absolute skill-level to any one form of labor over another. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fnref2" class="footnote-backref">↩︎</a></p></li><li id="fn3" class="footnote-item"><p>Since at least 1986, with the publication of Fred Brooks' paper, "No Silver Bullet — Essence and Accidents of Software Engineering", engineers and designers have been trained to distinguish two forms of complexity: essential and accidental. <em>Essential complexity</em> is inherent to the problem at-hand, what is called the domain or business logic; it exists prior to the introduction of the software tool and cannot be reduced by engineering alone. Accidental complexity, on the other hand, derives from the use of software in its own right, like the complexity of handling network latencies or multithreading; it may be unavoidable to some degree, but it is the only form of complexity that the software engineer can rightly try to eliminate. As a rule of thumb, the greater the complexity of the software, in either form, the greater its costs in both time and money. While it may be appropriate for the domain experts (ie, the business managers, workers and end users of the software) to reduce the essential complexity of the real system the software represents, any attempt by the software developers to forgo aspects of essential complexity can only represent a flaw of omission in their modeling. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fnref3" class="footnote-backref">↩︎</a></p></li><li id="fn4" class="footnote-item"><p>Newman, Chris. <a href="https://www.skywoman.community/post/choosing-software-the-case-for-using-erp-crm-scm-to-scale-farms" target="_blank" rel="noreferrer">"Choosing Software: The Case for Using ERP/CRM/SCM to Scale Farms"</a>. Jan 3, 2023. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fnref4" class="footnote-backref">↩︎</a></p></li><li id="fn5" class="footnote-item"><p>Scott, James C. <a href="https://theanarchistlibrary.org/library/james-c-scott-seeing-like-a-state" target="_blank" rel="noreferrer"><em>Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed</em></a>. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fnref5" class="footnote-backref">↩︎</a></p></li><li id="fn6" class="footnote-item"><p>James Muldoon and others extend Marx's concept to what they call <em>data commodity fetishism</em>, which he defines as "the perception of certain digital relationships between people (especially for communication and exchange) as having their value based not on the social relationships themselves but on the data they produce." See Muldoon, <em>Platform Socialism</em>, p. 18. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fnref6" class="footnote-backref">↩︎</a></p></li><li id="fn7" class="footnote-item"><p>Congden, Lee. <a href="https://www.redhat.com/en/blog/what-is-a-software-appliance" target="_blank" rel="noreferrer">"What is a Software Appliance?"</a><em>The Red Hat Blog</em>. Jan 25, 2008. <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html#fnref7" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
    <entry>
        <title type="html"><![CDATA[Runrig: A Plan for Socio-ecological Design]]></title>
        <id>https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html</id>
        <link href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html"/>
        <link rel="enclosure" href="https://www.runrig.org/open_field_system_all_600x745_bg_light.png" type="image/png"/>
        <updated>2023-04-16T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Free and open source software is a starting point, not the destination. Full computing autonomy requires control of the underlying infrastructure, something beyond the capacity of most individuals.]]></summary>
        <content type="html"><![CDATA[<main class="main" data-v-e6f2a212=""><header><h1>Runrig: A Plan for Socio-ecological Design</h1></header><div style="position:relative;" class="vp-doc _posts_the-runrig-plan-for-socio-ecological-design" data-v-e6f2a212=""><div><p>In its narrowest sense, Runrig is a technology framework for the communal management of a foodshed's digital assets, potentially spanning a network of cooperating foodsheds. To the degree that such information may control the flow of actual material resources, it may be viewed as a tool for the democratic management of food, labor, land and other resources that such information represents. In today's paradigm of "platform capitalism", technology companies derive their wealth and power by mediating interactions between users and capturing a portion of the value exchanged in the process. That portion only grows over time, even when the platform is no longer needed to mediate such an exchange.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn1" id="fnref1">[1]</a></sup> By recognizing this, and reclaiming common ownership of the technologies that mediate relations between farmers, distributors, drivers, wholesalers, retailers, commercial buyers and end consumers, Runrig aspires to nothing less than the total redistribution of that value, giving control of the wealth and power it creates back to the people who created it.</p><h2 id="three-layers-of-autonomy" tabindex="-1">Three Layers of Autonomy <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#three-layers-of-autonomy" aria-label="Permalink to &quot;Three Layers of Autonomy&quot;">​</a></h2><p>To understand what Runrig does, we can start by examining what kind of digital assets it is intended to manage. Partly for explanatory purposes, but also for reasons that will become clear later on, let's separate assets into two very broad categories: the data itself, and the software programs that capture, process and generally make use of such data. Free software proponents and privacy advocates have spilt a good deal of ink advancing the argument that true autonomy in computing requires control of both the data and the software, not to mention the hardware the whole system runs on.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn2" id="fnref2">[2]</a></sup> <sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn3" id="fnref3">[3]</a></sup> <sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn4" id="fnref4">[4]</a></sup> As the old saying goes: "There is no cloud, just someone else's computer."<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn5" id="fnref5">[5]</a></sup> Efforts to achieve computational autonomy, however, rarely exceed a vision for <em>individual autonomy</em>, and so are inevitably limited by <em>individual capability</em>. These solutions generally fall short in one of two ways: either they must curtail the range of functionality users have come to expect from so-called "Software-as-a-Service" (SaaS) platforms; or they foist the burdens of administering and maintaining those systems onto users who lack the capability to do so. Telling average users, who seek an alternative to predatory cloud platforms, that they can just spin up a service on their own server rack or VPS (then run backups and install updates all by themselves forevermore) is no better than playing the world's smallest violin for them.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn6" id="fnref6">[6]</a></sup> If free software and open source advocates focus too narrowly on licensing and sharing source code, while overlooking the actual capabilities this affords their users, then at best they can only offer <em>permissive freedom</em>, not <em>effective freedom</em>, as Luis Villa observes.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn7" id="fnref7">[7]</a></sup> In other words, they've granted permission to freely use the software, in a purely hypothetical sense, but not the real capability to use it in any practical or meaningful sense.</p><p>Runrig differs from other open source methodologies by coordinating the pooled capabilities of a community under democratic and cooperativist principles of governance. This way, ownership and control of both the data and the software can be shared collectively by all participants in a foodshed, while preserving the rights of individual users. To achieve this, Runrig comprises 2 - 3 functional layers:</p><ol><li>A single, collectively owned data storage provider, or "pod"<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn8" id="fnref8">[8]</a></sup> provider.</li><li>Many federated cooperative service platforms.</li><li>Local-first<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn9" id="fnref9">[9]</a></sup> and self-hosted applications (optional).</li></ol><p><img src="https://www.runrig.org/assets/stack-diagram.DSXrMUWy.svg" alt="Stack diagram"></p><p>With sufficient investment, the server racks, network infrastructure, brick-and-mortar facilities and other physical assets required to run these systems could be cooperatively owned as well. For now, however, Runrig restricts itself to the digital assets, since their storage and management can be cooperativized at a much lower upfront cost.</p><h3 id="the-data-provider" tabindex="-1">The Data Provider <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#the-data-provider" aria-label="Permalink to &quot;The Data Provider&quot;">​</a></h3><p>The first layer is a global commons, providing networked data storage to all its members as a shared service, while diffusing the costs and responsibilities of managing the underlying databases and infrastructure such a system entails. This layer corresponds to the data category of digital assets, as outlined above, and should be relatively indifferent to the shape of that data or how it's intended to be used.</p><p>This data provider can be thought of as a kind of cloud-based file system, like Dropbox or Google Drive, accessible from anywhere with an Internet connection, but with two key differences. First, it is collectively owned by all its members, not some corporation and its shareholders. So while it may not be each user's private computer, it is still <em>their computer</em> in a very real sense, with full governance rights over the infrastructure hosting their data, in addition to individual protections under the terms of service. Secondly, while it could in fact be used as a file system, its true potential lies in being a source of structured data, like an SQL database or even more modern low-code databases like NocoDB, a <em>libre</em> alternative to Airtable. This gives it the power to integrate more readily with a myriad of existing services via its API.</p><h3 id="service-platforms" tabindex="-1">Service Platforms <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#service-platforms" aria-label="Permalink to &quot;Service Platforms&quot;">​</a></h3><p>The second layer is a federation of platform cooperatives<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn10" id="fnref10">[10]</a></sup>, which can run the gamut of web-based applications and other software services, like the ones we're all accustomed to today. This layer corresponds to the software category of digital assets, but it draws its core data from the first layer, the data provider, linking the two layers programmatically as well as contractually. Services might include consumer-facing ecommerce sites or wholesale buying clubs, crop management software and record keeping, logistical and fleet management, bookkeeping, timesharing for certified kitchen space, etc. A platform is not limited to providing a single service, and it can have separate websites set up for separate services, or integrated as one. For example, there may be one site where retail customers place orders and another site where farmers track inventory through a different service. Critically, however, the two systems would still be integrated, sharing infrastructure, operating costs, and a unity of purpose. Users would also enjoy a seamless "single sign-on" between services, because the data provider can double as a secure identity provider as well.</p><p>Each of these service-oriented platform coops would function best within a geographically contiguous region, what we loosely call a foodshed, food zone<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn11" id="fnref11">[11]</a></sup> or bioregion. This way they can curate the services provided on their platform in order to best suit the needs of their members. They can even tailor the configuration and features of specific services as they choose. For example, if a platform wants to add a service for aggregating CSA orders, they can do so easily. If they need a specialized feature for a citrus CSA and one exists, they can enable it. If it doesn't already exist, they can sponsor its development and contribute the open source feature back to the commons. Meanwhile, other platforms could add features for a flower CSA instead, or omit the CSA service entirely. In this way, geographic regions offer a sensible criterion for bounding a platform's scope of functionality, since some services might make sense in one region or climate but not another. It also keeps governance more manageable, when not trying to accommodate the needs of a larger and more dispersed membership. In theory nothing prevents a platform from being as small or large as desired, but each platform will require some combination of time, expertise and money to maintain, so the distribution of those costs should be balanced with the desire for more localized control. Nevertheless, it shouldn't be necessary to impose strict boundaries on any one platform's range of coverage, and users would be free to join more than one platform if available and desirable. It may also prove useful to cover a more dispersed geographic area, for niche sectors of production or distribution, like pasture-raised meats or high-value crops. These are tradeoffs that should be left to the thoughtful deliberation of the constituents of each platform, so they can strike the right balance to meet their own goals given their unique circumstances.</p><p>This second layer, regardless of the particular platform or service, is also the layer that users will typically interact with. It will be the service platform's website where most users sign-up for an account, assuming they've been approved for membership in the cooperative that operates and governs that platform. In the same stroke, they will gain membership to the global data provider as well. They will be given a data pod that belongs exclusively to them, designated by a unique address, so that the first layer will also serve as an identity provider, much like an email address. The technical process can remain invisible to the user, but they can feel assured that their data is theirs to control. This is backed up by the fact that they hold a share in the governance of how the data provider stores their data, as well as a share in how any service platform they join is allowed to use it. If at any time they wish to join a different service or leave entirely, they can more easily bring their data along with them, because portability is a fundamental aspect of the design.</p><p>Ultimately, the service platforms only mediate the exchange between the data provider and the user, both in terms of the actual data exchange, as well as the service level agreements between all three parties. That is not to say that power users are prevented from interacting directly with the data provider, especially if they have programming knowledge; they just don't <em>have</em> to do so directly. They don't have to be aware how those data transactions work, or that the data provider even exists, although hopefully they will appreciate that regardless of what service platform they use, they retain certain rights over both their data and how the storage of it is administered.</p><h3 id="local-first-self-hosted-applications" tabindex="-1">Local-first &amp; Self-hosted Applications <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#local-first-self-hosted-applications" aria-label="Permalink to &quot;Local-first &amp; Self-hosted Applications&quot;">​</a></h3><p>The third layer is comprised of local-first applications, which individual users can install on their personal desktop and mobile devices, as well as self-hosted services, where the more technically savvy users are so inclined. These are not strictly necessary, however, and will only appeal to certain users at first. The other two layers are perfectly capable of providing fully featured web-based applications on their own, without the need to install and maintain purely local instances. Yet the possibility emerges quite spontaneously from the other two layers due to their intrinsically distributed nature. This affords the potential for additional peer-to-peer features and decentralized functionality, which could provide greater resilience to the overall network while also granting more freedom to individual users outside of those networks.</p><p>The details of this are still less critical to Runrig's initial development, but will be further explicated in the <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html">"Architecture"</a> section of this proposal, though it is still in draft.</p><h2 id="strategy" tabindex="-1">Strategy <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#strategy" aria-label="Permalink to &quot;Strategy&quot;">​</a></h2><h3 id="part-of-a-larger-ecosystem" tabindex="-1">Part of a Larger Ecosystem <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#part-of-a-larger-ecosystem" aria-label="Permalink to &quot;Part of a Larger Ecosystem&quot;">​</a></h3><p>Brought to its full potential, Runrig goes far beyond what a single software project or platform can achieve. Its main value proposition is that it opens up new ways for complex, distributed networks of groups and individuals to collaborate freely and productively. It would be arrogant to presume that we could bootstrap an inherently collaborative, widespread network from the ground up, in a few short development cycles with only a handful of engineers, designers and agriculturalists. Fortunately, that is not our task; we draw upon a rich substratum of prior work that has already established the necessary standards, technical infrastructure, methodologies and other essential building blocks that make Runrig possible.</p><p>Food standards and ontologies have been pioneered by such groups as the Data Food Consortium<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn12" id="fnref12">[12]</a></sup>, stewarded as an international collaboration by the Open Food Network. There also exists a full suite of agricultural tools from OpenTEAM<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn13" id="fnref13">[13]</a></sup>, including the farmOS Data Model<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn14" id="fnref14">[14]</a></sup>, which enjoy the continued support of the USDA, the Foundation for Food and Agricultural Research and other public and private partners.</p><p>These foundational projects are themselves part of a broader groundswell of technological advancements, particularly within the field of federated and peer-to-peer systems. Over the last two decades or more, Tim Berners-Lee and the W3C have spearheaded the drive for a Semantic Web,<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn15" id="fnref15">[15]</a></sup> which has made tremendous strides in just the last few years. Practical implementations of the Solid Protocol and WebID have now reached production, and community-supported servers are free to join or can be deployed independently as a testbed for Runrig's data provider.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn16" id="fnref16">[16]</a></sup> <sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn8" id="fnref8:1">[8:1]</a></sup> <sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn17" id="fnref17">[17]</a></sup> Parallel developments like ActivityPub, while not strictly applicable to food and agriculture, provide a template for how standards and shared toolchains can evolve by methods of open innovation and collaboration.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn18" id="fnref18">[18]</a></sup> <sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn19" id="fnref19">[19]</a></sup></p><p>By taking advantage of these open standards and tools, there is a lot that can be done by essentially snapping together off-the-shelf components. Combining that with the collaborative methodologies that have become all but customary in these communities, Runrig can enjoy a degree of near-term stability and long-term sustainability that are rarely found among early-stage startups.</p><h3 id="unique-advantages" tabindex="-1">Unique Advantages <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#unique-advantages" aria-label="Permalink to &quot;Unique Advantages&quot;">​</a></h3><p>These open source methodologies, free software libraries and proven models for standards development will all be instrumental in building our own network of service platforms for food production and distribution; however, Runrig's greatest advantage is how it can build directly on top of existing networks to deploy practical solutions today, while the larger technical infrastructure can grow incrementally, along with the networks of trust and social infrastructure undergirding the technical aspects.</p><p>This is where the separation between the data and software layers, as outlined above, proves so decisive. Because the service platforms are decoupled from the data source, they can be adapted to send and receive data to and from preexisting platforms based on compatible <em>libre</em> software systems, with very little additional overhead. This is not for the purpose of supplanting those platforms; rather, Runrig can complement their range of functionality and open up new avenues of potential development within the entire ecosystem.</p><p>The full value of this separation of concerns is best demonstrated by the way Runrig can prototype novel solutions that satisfy edge cases and fill critical gaps in the feature offerings of other <em>libre</em> software platforms. There will always be features that either fall outside the scope of more mature platforms, prove too costly to develop due to particular implementation details or accrued technical debt, or that merely get deprioritized in the context of more pressing concerns. These costs and other hindrances shrink to almost nothing, however, when an independent service can take full advantage of the existing platform's network and data storage, while still enjoying effective greenfield project status, unconstrained by previous design choices.</p><p>For example, one prototype we've discussed in the Skywoman MAIA Project is a post-planting survey for a producer coop to audit its member-farms and asses whether they are on target to match anticipated sales volumes. The coop manager only needs to send the survey out once or twice per season to about a dozen farms, but it could save her a lot of precious time otherwise spent on site visits.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn20" id="fnref20">[20]</a></sup> Runrig could host the data, structured as farmOS plans, assets and logs,<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn14" id="fnref14:1">[14:1]</a></sup> while also being compatible with the Solid protocol. This could be done with a self-hosted Solid Server<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn17" id="fnref17:1">[17:1]</a></sup> or even just a simple JSON document which could be transformed to a spreadsheet once the responses were collected; for this proof-of-concept, at least, the data requirements are miniscule. The survey itself could be created using SurveyStack, a low-code solution provided by Our Sci and OpenTEAM, with integrations already available with the farmOS Data Model.<sup class="footnote-ref"><a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fn21" id="fnref21">[21]</a></sup></p><p>While solutions like this have a payoff about on par with a Google Form plus a spreadsheet, the costs of developing and maintaining them with Runrig are still very low. Spreadsheets may be easier to create, but often prove much harder to maintain in the long-run. And what costs exist are not sunk costs; if the results aren't totally satisfactory, they can stick to the spreadsheets from then on, without losing that data or needing to export it from a third-party system. Maybe they like the concept, but want something more "off the shelf" like farmOS or Inrupt, in which case the data is easily ported there. And of course if they're happy enough with the system as it is, or want to continue building its potential to meet their unique circumstances, development can continue apace with Runrig. Best of all, none of these options are mutually exclusive, and in fact, the coop could keep on using the latter two options in parallel, getting the best of both worlds, without any serious costs associated with keeping the two redundant data sources synchronized.</p><p>That's where Runrig can most benefit other platforms in the ecosystem, by catching the spillover of feature creep that inevitably besets older software projects, while accommodating users for whom the lack of those features would otherwise be a deal breaker. A synergy arises between Runrig and other free software platforms, expanding the user base for each, which wouldn't be possible if Runrig's data and service layers were more tightly coupled.</p><h3 id="ecology-over-architecture" tabindex="-1">Ecology Over Architecture <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#ecology-over-architecture" aria-label="Permalink to &quot;Ecology Over Architecture&quot;">​</a></h3><p>Runrig will center ecological design over any specific technological architecture. Ecology, in this sense, encompasses the technological, social and biotic aspects of design, together and all at once. Accordingly, we strive to make those designs adaptive to the whole, rather than prescriptive in the particular.</p><p>In a practical sense, this grants us greater freedom to experiment with these technologies. The example of the auditing survey mentioned above is a prime example. The solution is small, almost trifling, and it risks very little; however, it can have very real benefits, meeting the most immediate, material concerns of its users. While it can be tossed aside if it proves unhelpful, it could just as well form the kernel of a much larger system. In that sense, it's hardly even fair to call it a prototype. This is yet another direct consequence of separating the data provider from the services, an intrinsic element of the overall design that can be achieved from the start, without temporary expedients. In this way, the eventual contours of the superstructure are imprinted at the very laying of its foundations.</p><p>This design would give Runrig some rather attractive scaling properties, but "scale" alone is grossly inadequate for describing the full benefits. The continued ability for experimentation and free play, <em>jeu libre</em>, throughout the lifespan of the project, and the potential it yields cannot be understated. The design choice to enable the collective stewardship of data, together with the free and open sharing of the software, is as much a principle of social design as it is a technological one. It imparts a vitality and iterative quality to the project, akin to the Agile methodology, but extending well beyond mere product development. The evolution of the software system is only one factor in the evolution of the broader social and natural systems in which it is embedded. Experiments, whether they succeed or fail; ad hoc solutions, whether they can be adapted to general uses or not; shared techniques and information, whether that sharing is reciprocated or not — all of these outcomes will be metabolized just the same within an open system of communal ownership, and so their lessons and shared progress always nurture the whole.</p><p>It should be pointed out that the separation between the data and service layers is by no means absolute; again, such prescriptiveness is to be avoided. The services will always have some data which they persist themselves, and there's obviously no way the data provider could provide data if it were not itself acting as a service. The key abstraction is more social than technical in nature, intended to deconstruct the prevailing notion that both data and services must be centralized with strict top-down control, as well as the countervailing notion that our best alternative is strict decentralization, where data and services are still co-located in discreet instances. The aim is to empower new, imaginative configurations that instead emphasize the freedom of users, both as individuals and collectively, to determine the location of their data, how it is used and in what directions it flows. Tight coupling of the two layers restricts that movement, stifling the health of the overall ecosystem, to say nothing of what that means for the effective freedom of the people within it.</p><p>Technology can be far more than an extension of the greater capitalist apparatus, alienating us more and more each day from the living world and from each other; it can be reclaimed as a vital part of human life. To invite ecological characteristics back into our technologies and design is to reintegrate them with the natural and social worlds.</p><h2 id="next-steps" tabindex="-1">Next Steps <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#next-steps" aria-label="Permalink to &quot;Next Steps&quot;">​</a></h2><p>In the <a href="https://www.runrig.org/posts/roadmap-2024.html">Runrig Roadmap for 2024</a> we propose a <a href="https://www.runrig.org/posts/roadmap-2024.html#three-phase-business-plan">3-phase business model</a> for a workers cooperative, which can then steward the development of the platform cooperatives and eventually "One Big Data Co-op," à la Bill Haywood and the Wobblies. Right now as a volunteer-driven group, we're in <em>Phase Zero</em>. Before taking any contracts or pursuing grants for the following phases, we're building out one or two <a href="https://www.runrig.org/posts/roadmap-2024.html#projects-for-2024">reference implementations</a> to test the viability of the model at each phase of development. We're holding three open workshops each month, along with community chat rooms and discussion boards, so anyone can <a href="https://www.runrig.org/get-involved.html">get involved</a>. As we progress, we're actively seeking partnerships and collaborations with similarly aligned organizations, and eventually hope to recruit farmers, food &amp; tech workers and activists as coop members, so <a href="https://buttondown.email/runrig" target="_blank" rel="noreferrer">sign up</a> for our newsletter to receive occasional updates.</p><p>The Runrig Plan is a living document that describes the main design principles of the social and ecological technologies we are building now and in the near future. In addition to this overview, two appendices are also presented now, though they are still in a very rough stage of draft. The <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-architecture.html">"Architecture"</a> page will go into more technical detail of the underlying software and networking systems involved in the implementation of Runrig, while the <a href="https://www.runrig.org/posts/the-runrig-plan-appendix-ecology.html">"Ecology"</a> page will cover more of the social, environmental and economic aspects of the plan, as well as governance structures and legal considerations.</p><h2 id="references" tabindex="-1">References <a class="header-anchor" href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#references" aria-label="Permalink to &quot;References&quot;">​</a></h2><hr class="footnotes-sep"><section class="footnotes"><ol class="footnotes-list"><li id="fn1" class="footnote-item"><p>Muldoon, James. <em>Platform Socialism: How to Reclaim our Digital Future from Big Tech</em>. p. 14-15. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref1" class="footnote-backref">↩︎</a></p></li><li id="fn2" class="footnote-item"><p>Stallman, Richard. <a href="https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html" target="_blank" rel="noreferrer">"Who does that server really serve?"</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref2" class="footnote-backref">↩︎</a></p></li><li id="fn3" class="footnote-item"><p>Tisne, Martin. <a href="https://www.technologyreview.com/2018/12/14/138615/its-time-for-a-bill-of-data-rights/" target="_blank" rel="noreferrer">"It’s time for a Bill of Data Rights"</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref3" class="footnote-backref">↩︎</a></p></li><li id="fn4" class="footnote-item"><p>Cyphers, Bennett and Cory Doctorow. <a href="https://www.eff.org/wp/interoperability-and-privacy" target="_blank" rel="noreferrer">"Privacy Without Monopoly: Data Protection and Interoperability"</a>. Feb 12, 2021. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref4" class="footnote-backref">↩︎</a></p></li><li id="fn5" class="footnote-item"><p>Watterson, Chris. <a href="https://www.chriswatterston.com/article/success-of-my-there-is-no-cloud-sticker" target="_blank" rel="noreferrer">"The Success Of My 'There Is No Cloud' Sticker"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref5" class="footnote-backref">↩︎</a></p></li><li id="fn6" class="footnote-item"><p><a href="http://howfuckedismydatabase.com/nosql/" target="_blank" rel="noreferrer">"Fault-tolerance"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref6" class="footnote-backref">↩︎</a></p></li><li id="fn7" class="footnote-item"><p>Villa, Luis. <a href="https://lu.is/blog/2016/03/23/free-as-in-my-libreplanet-2016-talk/" target="_blank" rel="noreferrer">"Free as in...?"</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref7" class="footnote-backref">↩︎</a></p></li><li id="fn8" class="footnote-item"><p>Solid Project. <a href="https://solidproject.org/users/get-a-pod" target="_blank" rel="noreferrer">"Get a Pod"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref8" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref8:1" class="footnote-backref">↩︎</a></p></li><li id="fn9" class="footnote-item"><p>Kleppmann, Martin et al. <a href="https://www.inkandswitch.com/local-first/" target="_blank" rel="noreferrer">"Local-first software: You own your data, in spite of the cloud"</a>. <em>Ink &amp; Switch</em>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref9" class="footnote-backref">↩︎</a></p></li><li id="fn10" class="footnote-item"><p>Scholz, Trebor. <a href="https://rosalux.nyc/pslatform-cooperativism-2/" target="_blank" rel="noreferrer"><em>Platform Cooperativism: Challenging the Corporate Sharing Economy</em></a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref10" class="footnote-backref">↩︎</a></p></li><li id="fn11" class="footnote-item"><p><a href="https://betterfoodtraders.org/why-it-matters/the-food-zones/" target="_blank" rel="noreferrer">"The Food Zones Explained"</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref11" class="footnote-backref">↩︎</a></p></li><li id="fn12" class="footnote-item"><p>Data Food Consortium. <a href="https://www.datafoodconsortium.org/en/our-standard/" target="_blank" rel="noreferrer">"Our Standard"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref12" class="footnote-backref">↩︎</a></p></li><li id="fn13" class="footnote-item"><p>OpenTEAM. <a href="https://openteam.community/access-tools-and-support/" target="_blank" rel="noreferrer">"Access Tools and Support"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref13" class="footnote-backref">↩︎</a></p></li><li id="fn14" class="footnote-item"><p>farmOS. <a href="https://farmos.org/model" target="_blank" rel="noreferrer">farmOS Data Model</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref14" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref14:1" class="footnote-backref">↩︎</a></p></li><li id="fn15" class="footnote-item"><p>The World Wide Web Consortium. <a href="https://www.w3.org/standards/semanticweb/" target="_blank" rel="noreferrer">"Semantic Web"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref15" class="footnote-backref">↩︎</a></p></li><li id="fn16" class="footnote-item"><p>Solid Project. <a href="https://solidproject.org/TR/" target="_blank" rel="noreferrer">"Solid Technical Reports"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref16" class="footnote-backref">↩︎</a></p></li><li id="fn17" class="footnote-item"><p>Solid Project. <a href="https://solidproject.org/self-hosting/css" target="_blank" rel="noreferrer">"Running your own Solid server"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref17" class="footnote-backref">↩︎</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref17:1" class="footnote-backref">↩︎</a></p></li><li id="fn18" class="footnote-item"><p>Lemmer Webber, Christine. <a href="http://dustycloud.org/blog/activitypub-is-a-w3c-recommendation/" target="_blank" rel="noreferrer">"ActivityPub is a W3C Recommendation"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref18" class="footnote-backref">↩︎</a></p></li><li id="fn19" class="footnote-item"><p>Lemmer Webber, Christine. <a href="https://www.fsf.org/blogs/community/victory-for-libre-networks-activitypub-is-now-a-w3c-recommended-standard" target="_blank" rel="noreferrer">"Victory for libre networks: ActivityPub is now a W3C recommended standard"</a>. <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref19" class="footnote-backref">↩︎</a></p></li><li id="fn20" class="footnote-item"><p>Skywoman MAIA Project. <a href="https://github.com/skywoman/multifarm-aggregation-info-arch/tree/main/interviews/2022_08_12--Kip_Curtis_and_Richland_Gro_Op" target="_blank" rel="noreferrer">"OSU Microfarm Project &amp; Richland Gro-Op"</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref20" class="footnote-backref">↩︎</a></p></li><li id="fn21" class="footnote-item"><p>SurveyStack. <a href="https://www.surveystack.io/" target="_blank" rel="noreferrer">"Survey software designed to empower shared community knowledge."</a> <a href="https://www.runrig.org/posts/the-runrig-plan-for-socio-ecological-design.html#fnref21" class="footnote-backref">↩︎</a></p></li></ol></section></div></div></main>]]></content>
        <author>
            <name>Jamie Gaehring</name>
            <email>jamie@runrig.org</email>
            <uri>https://jgaehring.com/</uri>
        </author>
    </entry>
</feed>