HedgeDoc - Collaborative markdown notes

## A Response to the Proposed ExCUE Model <span style="font-size:large;" > Emerging from sessions at the D:food/web Cultivation Station, the [ExC] & [Utility-Enterprise Hybrid Entity] funding models (together as ExCUE) were drafted in the weeks following DWeb Camp 2024. While they promise much to privately funded and institutionally supported contributors to the free & open source ag-tech commons, they raise concerns for independent contributors and the wider community of unaffiliated supporters. [The Runrig Plan] is presented as an alternative model for achieving many, though not all, of the same objectives. </span> ##### Presentation by Jamie Gaehring ###### Last edited: 2024-09-27 [Utility-Enterprise Hybrid Entity]: https://docs.google.com/document/d/1nOcqaq-BkJxL6091bGVb9D13EPj24IMYuCHILmrzYws/view [ExC]: https://docs.google.com/document/d/1aQeXhBCWnZ5c4QWqRvGJmTShcHn90vRuh4Wc0vJU98U/view [The Runrig Plan]: https:/runrig.org/overview <aside class="notes"> Speaker Notes </aside> --- ## The Problem Space 🎈 _(from an outsider's perspective)_ ---- ### What these models address 🍪 - How to prevent private IP from becoming orphan works or abandonware - How to scale, stabilize cash flow, ensure ROI - How to fix the "many-headed hydra" of iterative FOSS development 🐲 - General coordination & administrative support for all the above ---- ### Issues left unaddressed 🪚 _(again, purely as an outsider looking in)_ ---- ### Revenue 💸 - Revenue model left up solely to individual founders? - How then to ensure ROI? - Back to biz-as-usual VC model? <span class="fragment"> i.e., for every 99 that fail, 1 is a 🦄?</span> <aside class="notes"> <ul> <li>Revenue, not ordinarily a concern of VC's</li> <li>But they also don't guarantee ROI for every startup in portfolio</li> <li>To compensate for the many that fail, one has to win really, really big, hence...</li> </ul> </aside> ---- ### Revenue (cont'd) 💸 - What about independent contractors & other unaffiliated contributors? - All our revenue comes from dev time - ...does our labor pay for capped returns? - So what's the indy dev get out of this? 🤷🏽 ---- ### Capital assets 🏦 ###### (if not revenue) - Any plan to produce or acquire them? - If so, from where? by whom? - Can free software be a capital asset? - If not, is there any intention to relicense free software under new, non-free terms? - What happens to IP assets in bankruptcy? <div class="fragment fade-in" style="font-size:.75em;text-align:right;"> (back to 🦄?) </div> <aside class="notes"> <ul> <li>Assets may be held by the Utility or each Enterprise</li> <li>Would the collaboration monster still work with the GPL?</li> <li>Physical or service-level infrastructure seems worth exploring</li> <li>Creditors will claim rights to assets if priority rights have not been carefully specified and common assets shielded</li> </ul> </aside> --- ## Other Concerns ( _take with a HEFTY grain of salt!_ 🧂) ---- ### ©️ Licensing <span class="fragment strike" >and</span> the Commons™️ - Does this model undervalue indy & volunteer contributors, plus the generative qualities of the free software community as a whole? - Does it risk jettisoning that value and estranging contributors if this plan stifles or significantly alters those community dynamics? <aside class="notes"> <ul> <li>Community already contributed HUGE portion of existing value</li> <li>Membership not feasible / desirable for indies</li> <li>Restricting rights to members seems essential, whether license or trademark</li> <li>Exceptions doubtful to work</li> </ul> </aside> ---- ### Costs of complexity 😵‍💫 The utility's funding pool must simultaneously... - buy out private IP from exiting founders - yield capped returns for going concerns <span class="fragment" data-fragment-index="3" style="font-size:large;">(eventually)</span> - cover administrative and operating costs of the utility organization's board and staff - leave any profit for the individual enterprises* - not piss off indy contribs 🤬 ###### \* Assuming some of their revenue is reinvested into the funding pool or used to pay down returns; it's unclear if that's the case. <aside class="notes"> <ul> <li> Investors: what do they hold a stake in? <ul> <li>Enterprise(s)</li> <li>Utility</li> </ul> </li> <li> What comes out of... <ul> <li>total funding pool, v.</li> <li>enterprises revenues?</li> </ul> </li> </ul> </aside> ---- ### Need for complexity? 🤔 - Is all this necessary? - What about unforeseen costs? - How and when would we know if the costs become too great? - Can we afford that risk? - ...🦄? ---- ### Complexity: <br>Essential or Accidental 🪃 <p class="fragment" style="font-size:10px;line-height:12px;margin-top:-1em;">Brooks, Fred. <a href="https://www.cs.unc.edu/techreports/86-020.pdf">"No Silver Bullet—Essence and Accident in Software Engineering"</a>. <em>Proceedings of the IFIP Tenth World Computing Conference</em>: 1069–1076, 1986.</p> <div style="text-align: left; position: relative; overflow: visible;"> <div class="fragment fade-in"> ##### Which is it if we need to pay investors or acquire private IP? </div> <div class="fragment fade-in"> ###### — Sadly, it may be essential 😕 </div> <div class="fragment fade-in"> ##### ...if we don't need any of that? </div> <div class="fragment fade-in"> ###### — I'll wager it's incidental <span class="fragment fade-in"> _and avoidable!_ 🦸🏽</span> </div> <div class="fragment fade-in"> ### But how? <img src="https://sfo2.digitaloceanspaces.com/dwebcamp/uploads/ffca0a73-0d99-442b-9454-e4e04faa91e1.png" width="30%" style="position: absolute; bottom: -10%; right: 10%;border: none;"> </div> </div> </div> --- ###### _[Enter:]_ ## Runrig 🚜 A method for socio-ecological design 🌱 ---- ### What Runrig does __not__ address - Salvaging orphan works & abandonware - ROI to past or future investors ---- ### What Runrig __does__ address - A revenue model, providing: - fair, stable income for developers - affordable services for food producers - Surmounting local maxima in the fitness landscape - a.k.a. the "many-headed hydra" - iterative free software development can still be good! ---- ### The Fitness Landscape #### a.k.a., Mount Improbable <iframe width="560" height="315" src="https://www.youtube.com/embed/YT1vXXMsYak?si=IQfdU1vZt9GqbnHy&mute=1&autoplay=0&start=1724" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen csp="frame-src youtube.com www.youtube.com;"></iframe> <p style="font-size:10px;line-height:12px;margin:-1em 0 0 0;">Source: <a href="https://youtu.be/YT1vXXMsYak?t=1724">https://youtu.be/YT1vXXMsYak?t=1724</a>.</p> ---- #### Local Maximum vs. Global Maximum ![](https://upload.wikimedia.org/wikipedia/commons/e/ea/Visualization_of_two_dimensions_of_a_NK_fitness_landscape.png) <p style="font-size:10px;line-height:12px;margin:-1em 0 0 0;">Source: <a href="https://en.wikipedia.org/wiki/NK_model">https://en.wikipedia.org/wiki/NK_model</a>.</p> <aside class="notes"> <ul> <li> Evolutionary Biology <ul> <li>You arrive at a local maximum</li> <li>Want to reach the <em>global</em> maximum</li> <li>Can't move any direction w/o decreasing fitness</li> <li>No matter how much greater your eventual fitness</li> </ul> </li> <li> Richard Dawkins "Mount Improbable" @ Royal Inst. 1991 <ul> <li>Nautilus, pinhole camera eye</li> <li> Other cephalopods (squid, oct) & vertebrates have lenses </li> <li>Convergent evolution</li> <li>Nautilus, living fossil, got stuck on a local max</li> </ul> </li> <li> Not just a metaphor but a <b>Mathematical Model</b> </li> <li> Immunology, Team Mgmt, Sociology, Optimization Problems, other complex systems, including studies of <b>Technological Evolution</b> </li> <li>Dawkins argues no intelligent design in natural selection</li> <li> But technology <em>is about design</em>, not natural selection </li> <li>Natural selection only if we isolate our designs</li> </ul> <p>The <b>NK model</b> is a mathematical model described by its primary inventor Stuart Kauffman as a "tunably rugged" fitness landscape. "Tunable ruggedness" captures the intuition that both the overall size of the landscape and the number of its local "hills and valleys" can be adjusted via changes to its two parameters, <span class="mwe-math-element"><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/f5e3890c981ae85503089652feb48b191b57aae3" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.338ex; width:2.064ex; height:2.176ex;" alt="{\displaystyle N}"></span> and <span class="mwe-math-element"><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/2b76fce82a62ed5461908f0dc8f037de4e3686b0" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.338ex; width:2.066ex; height:2.176ex;" alt="{\displaystyle K}"></span>, with <span class="mwe-math-element"><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/f5e3890c981ae85503089652feb48b191b57aae3" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.338ex; width:2.064ex; height:2.176ex;" alt="{\displaystyle N}"></span> being the length of a string of evolution and <span class="mwe-math-element"><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/2b76fce82a62ed5461908f0dc8f037de4e3686b0" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.338ex; width:2.066ex; height:2.176ex;" alt="{\displaystyle K}"></span> determining the level of landscape ruggedness. </p> </aside> ---- ### Runrig's general strategy ###### Start with many 🍪's (smaller the better) then build slowly to the big 👾 | VC Methods | Runrig Methods | | :-------------------- | :------------------------- | | <span>Scaling Production</span> | <span>_Expanding_ __REACH__</span> | | <span>Consolidating Markets</span> | <span>_Organizing_ __SUPPORT__</span> | | <span>Accumulating Capital</span> | <span>_Distributing_ __CONTROL__</span> | | <span>Seeking Rents</span> | <span>_Diffusing_ __COSTS__</span> | --- ### Three-Phase Organizing Model 1. Middleware, a.k.a. "glue services" 🍯 2. The One-stop Platform Co-op Shop 🛒 3. One Big Data Union 🐈‍⬛ ---- ### 1. Middleware / "glue services" 🍯 Targeted interventions that catch the spillover from other FOSS projects' [`wontfix`] issues, in the form of - API integrations - extensions, plugins, middleware, etc. - lightweight local-first applications - component libraries - thin clients - and so on... [`wontfix`]: https://github.com/search?type=issues&q=label%3Aenhancement+label%3Awontfix+is%3Aclosed ---- ### 2. The One-stop <br>Platform Co-op Shop 🛒 - Bundle up complementary applications, middlewares & services - Food & ag-specific services: eg, farmOS, Brinjel - Generic services: eg, Nextcloud, Baserow - <b>Appropriate to a given community</b>, suited to their needs & bioregion - Single Sign-On (SSO) & other niceties reduce complexity for end-users ---- ### 2. The One-stop <br>Platform Co-op Shop (con'd) 🛒 - Full ownership & control to the community - Farmers, co-ops, consumers, buyers clubs, land defenders, small biz, etc. - Worker co-op(s) of developers, designers, & TSPs are paid to develop, maintain, & provide varying levels of support for the platforms ---- ### 3. One Big Data Union 🐈‍⬛ <ul> <span class="fragment"><li> A global <b>data provider</b> serving the platforms collectively </li></span> <span class="fragment"><li> Leveraging standards & protocols <span class="fragment"> — e.g., Solid protocol, the DFC Standard, the farmOS Data Model, etc. </span> <span class="fragment"> — in order to...</span> <ul> <span class="fragment"><li> encourage greater interoperability between services </li></span> <span class="fragment"><li> relieve computational & storage burden on platforms & local devices </li></span> </ul> </li></span> </ul> ---- ### 3. One Big Data Union (cont'd) 🐈‍⬛ - A global <b>data trust</b> or data co-op, owned & controlled by its users - Comprising 2 member classes: - <b>Data Members:</b> Individuals, farms, biz, etc. who store their data - <b>Service Members:</b> The service platforms themselves acting on behalf of their members ---- ..._plus a whole lot more details at [runrig.org](https://runrig.org)_ 🚜 --- ### Case Study: Farm Flow A Runrig pilot application currently in development. - Adapted from a physical whiteboard - Coordinate & optimize team execution of SOPs - Based on data analysis of organic field practices - Created __entirely by-&-for Minnesota farmers__ - It's their baby, Runrig only serves as midwife ---- #### Farm Flow IRL <div> <img src="https://sfo2.digitaloceanspaces.com/dwebcamp/uploads/4a22d02e-1f10-48ee-b7e5-d7d88d8b6510.jpg" alt="The original Farm Flow whiteboard" width="75%" style="border: none;" > </div> ---- ### Farm Flow: Development Cycle - ~$50k of combined grant funding & farmer contributions - Slated for launch Winter 2024-25 - Deliverables - __Low Fidelity Pilot__ _(compl. Jul 2024)_ - __Service Integration__ _(est. Nov 2024)_ - __High Fidelity Pilot__ _(est. by Feb 2025)_ ---- ### Deliverable #1: Low Fidelity Pilot - Minimal needed for core CRUD operations - Local-first, browser-based app - IDB for storage & hosted on [CDN] at no cost - Import & export from a single JSON file - Domain-Driven Design (_follow the model!_) [CDN]: https://farm-flow-board.pages.dev/ ---- ### Deliverable #2: Service Integration - Backend server (TBD): - farmOS, LiteFarm, _both?_ - That'll cover: - synchronization, mobile, et al. ---- ### Deliverable #3: High Fidelity Pilot - Flesh out a robust UX, features, brand, etc. - Feedback from users - Feedback from FOSS community - Bells, whistles, a final spit-polish - 1.0 in production by Feb 2025 🤞 --- ## So what now? - Can these two models co-exist? (I think yes) - Can they be mutually supportive? (also yes) - What do they have to learn from each other? 🤔 - 🦄 + 🚜 = 🪄 ?