The Commons Has No Ledger for This

by Leo Gaggl • opinion

A three-part series on licensing and the economics of digital sovereignty was planned: how the commons got built, how Europe is choosing to defend it, how the AI stack could be governed as one. Then Martin Owens, an Inkscape developer and member of its project leadership committee, replied to part one on Mastodon, in two posts stitched together by the character limit, and pointed straight at something the series had missed entirely.

The argument, paraphrased faithfully rather than quoted: free software licences protected the artefact but never built a claim on being paid for making it, and that gap wasn’t incidental, it was ideological. The FOSS libertarian tradition hand-waved away the question of transacting labour for money because it never wanted workers in the first place. And the damage compounds, because “must code, for free, in your spare time” filtered out everyone whose contribution wasn’t a pull request: translators, testers, documentation writers, community support. We never invited in the millions of people who could have contributed something other than code, and in refusing to build a mechanism for paying any of it, we ensured neither side ever had the other’s back.

It landed harder than a reply thread usually does, because I’d already been circling the same problem from a different direction. GrowGood, the farm management platform I work on, is built on Valueflows and REA accounting precisely so the labour behind agricultural and food-system data is a recorded fact rather than an assumption buried somewhere else. And at Growing Data Foundation, the not-for-profit GrowGood sits inside, we’ve started looking seriously at Holochain’s hREA implementation, and tools like Unyt and Acorn built on top of it, for tracking, and eventually compensating, volunteer contribution rather than running on goodwill indefinitely. Nothing there is decided. But they weren’t telling me something abstract. They were naming, more precisely than I had, the gap I’d been trying to design around from the infrastructure side for months.

That’s not a footnote, it’s a gap this series left wide open, and it deserves more than a reply thread. So: this is the +1. Three parts became three-plus-one, in public, because they were right, and because rounding the series out with the human side of the ledger was the honest way to finish what the first three parts had left out.

The Ideology, Not Just the Oversight

It’s worth being precise about what kind of gap this is, because “free software forgot to build a payment system” undersells it. Richard Stallman’s distinction, free as in freedom, not free as in beer, explicitly permitted commercial redistribution. You could always sell GPL’d software. The gap isn’t in the licence text. It’s in what the movement built institutionally around the licence.

Eric Raymond’s 1998 essay “Homesteading the Noosphere” made the alternative explicit and, at the time, made it sound like a feature. Hacker culture, he argued, operates as a reputation economy that exists precisely because material scarcity has been solved: there’s enough compute, enough bandwidth, enough of everything material that the only scarce good left worth competing for is respect. It’s a gift culture, deliberately positioned against an exchange culture. The framing was clever and the essay was influential, and it also quietly wrote wage labour out of the picture as something beneath the movement’s notice. If the only thing worth having is reputation, the question of who can afford to spend their unpaid time earning it never has to be asked.

That’s the “why would we want workers” instinct Martin named. It isn’t a bug in the licensing. It’s a founding assumption, made mostly by people with day jobs, who didn’t personally need the commons to pay them, and so never designed for the case where it would need to.

There’s a sharper version of that founding assumption too. The GNU project’s four freedoms include the freedom to modify the software to suit your needs, but that freedom only means something in practice if you can already code, or can pay someone who can. Contributing money is how someone without either takes responsibility for their own use and turns themselves from a user into a contributor. Stripping money out of the picture doesn’t protect that freedom equally for everyone; it protects it only for the people who already had the skill or the spare time to exercise it themselves. A movement that treated wage labour as beneath its notice was, without quite meaning to, also deciding whose freedom to modify actually counted.

Who Got Filtered Out

Three people intently debugging code together on laptops, pair programming
"Pair programming" by Damien Pollet (CC BY-SA 2.0)

The coding filter did more than underpay coders. It set the entry price of participation at “can write code, and can afford to do it unpaid,” which quietly excluded almost everyone else who might have contributed something real: the person who could translate documentation into a language the project had never reached, the person who tests a release candidate against hardware the maintainer doesn’t own, the person who answers the same forum question for the fortieth time so the maintainer doesn’t have to.

In a separate, private note, Martin pushed the point further. Wikipedia and OpenStreetMap converge on an objective truth, and that shared target is what lets undirected, random contribution add up to something coherent: more people can invest time in parallel, and they barely need to coordinate with each other beyond a small policy-making elite, because the target does the coordinating for them. Software isn’t truth. It’s design, and a design targets specific people, not a universal fact. Who it targets decides who can meaningfully contribute to it, which means software starts with both a narrower potential contributor pool than a truth-convergent project and a harder job, since it has to serve actual people rather than aim at a shared ideal. It’s also, they suggested, why the two kinds of commons treat the same behaviour so differently: being paid to write a Wikipedia page favourably for a politician is corruption, because it substitutes someone’s interest for the shared truth the whole project is converging on, while designing software around a specific paying user’s needs isn’t, because serving a defined set of people well was always the point. The economic filter this post has been describing sits on top of that structural one, not instead of it.

GrowGood keeps running into this in miniature. Getting firmware working on a sensor is one kind of labour. Documenting the termination resistor requirement that took a day and a half to diagnose, so the next person doesn’t lose a day and a half too, is a different kind of labour, and it’s not smaller. Neither shows up the same way in a commit graph, and only one of them has ever had anything resembling a funding mechanism attached to it.

The cost of leaving that unaddressed is not abstract. Mark Qvist, the developer behind the open-source mesh networking stack Reticulum, stepped away from active development in late 2025 after years of unpaid work, citing burnout and the financial impossibility of sustaining it alongside supporting his family, a story I covered in Open Source Is The Hope, But It Needs Our Help. Log4j, maintained by a small volunteer team, became a global emergency in December 2021 not because the code was bad but because critical infrastructure had been resting on unpaid, under-resourced labour for years, a pattern familiar enough that it has its own webcomic. Nadia Eghbal’s 2016 report for the Ford Foundation, Roads and Bridges, is the fullest documentation of exactly how structural this is: the software equivalent of public infrastructure, maintained with none of the funding public infrastructure would normally receive.

Why Tip Jars Aren’t the Fix

The commons’ actual response to this, over the past decade, has mostly been GitHub Sponsors, Ko-fi, Liberapay, Open Collective, Tidelift. These matter. I’ve pointed people towards them myself. But they’re patronage, not a claim. They depend on the goodwill and visibility of whoever happens to have a donate button, they overwhelmingly favour the contributor whose name is on the repository over the 12 people who tested, translated, and documented around them, and they don’t scale, because goodwill isn’t a resource allocation mechanism. It’s what you reach for when you don’t have one.

Their point stands against tip jars too: the problem was never that free software lacked generosity. It lacked structure. A donate button records that someone felt like giving money on a particular day. It doesn’t record that a specific unit of labour happened, who did it, or what it’s worth relative to every other contribution to the same project. Without that record, there’s nothing to build a fairer distribution mechanism on top of, even if the money were there.

Trust Needs a Membrane Too

Money works by anonymising trust. It lets you transact with someone you have no reason to believe in, which scales efficiently, but it’s strictly worse than transacting with someone you already trust. Your kid taking the bins out doesn’t come with a tap-to-pay and a 10% tip. A neighbour lending you a pair of shears doesn’t trigger a payment negotiation. Businesses solve this for paid labour with what Martin calls an HR membrane: a boundary around what the company actually is on the inside, where planning and hierarchy do the work, not a market at all, until that same business steps back out through the boundary into a labour market on the other side, where money and contract terms take over doing the work trust would otherwise do. It’s why hiring someone feels like a change in kind rather than degree, and why whistleblowing gets punished as betrayal from within rather than treated as ordinary competition from without. A coop, a contractor network, the tradesperson who fixes your burst pipe: all of them dodge the membrane, and all of them pay for it in constant per-job trust negotiation. Do I know you. Can you afford me. Is there a mate’s rate.

Free software built trust a different way: common contribution, in-person familiarity, conference badges, mailing-list history, reputation earned inside one specific project. It worked, as a high-trust community. Then it opened contribution to the entire world and never built an equivalent mechanism for economic trust, only ever hardening its defences against security threats instead. Android is the sharpest illustration of what happens without one. It’s free software but not open source, because it has exactly one developer, Google, and one population it serves. That’s a membrane too, just an unlabelled one, and it inherits the same problems as working inside a badly run company, wearing a different licence.

GrowGood sits right on that fault line already. The person testing firmware against hardware I don’t own, or answering the same sensor-calibration question for the fifth time, isn’t a stranger I’m transacting with at arm’s length. I trust their judgement because I’ve watched it hold up before. The day Growing Data Foundation starts routing real payment toward that kind of work, through hREA or anything else, we inherit Martin’s problem whether we plan for it or not: build no membrane, and every one of those relationships turns into a per-job negotiation over whether the trust was ever real.

Tip jars fail for the reason the last section named: no structure. Membrane is the missing word for what that structure would actually be. A ledger records what happened. A membrane routes trust, so labour, expectation, and need can move between people who don’t already know each other, without pretending everyone’s equally trustworthy, and without pretending a market can substitute for actually knowing someone. Companies build membranes by accident, usually badly. Nothing says a commons has to.

What a Ledger for This Actually Looks Like

This is where Valueflows and hREA are relevant: an existing accounting vocabulary, not a hypothetical, built for exactly the kind of membrane the previous section describes.

Valueflows extends the REA accounting model, Resources, Events, Agents, first formalised by accounting professor William McCarthy in 1982, into an open vocabulary for economic coordination across multiple independent parties rather than inside a single firm’s books. Lynn Foster and Bob Haugen, working with the open value network built around Sensorica in Montreal from 2011 onward, extended REA into Valueflows specifically because Sensorica needed to answer a question conventional accounting has no good answer for: when a physical product is built by a loose, changing network of contributors, none of them employees, how do you record who did what, and split what it earns accordingly? hREA is the Holochain implementation of that vocabulary: agent-centric, peer-to-peer, with no central ledger authority required, which matters for a commons project precisely because no single company ends up owning the accounting layer either.

The part that answers their argument directly: in the Valueflows model, “work” is a first-class economic event, the same standing as producing a resource, transferring it, or consuming it. It carries its own effort quantity, its own provider and receiver, its own timestamp, independent of whether it produced a code commit, a translated string, a triaged bug report, or a Discord answer to a confused new user. Nothing in the model privileges code over translation. Both are recordable, both are claimable, both can accumulate into a documented, auditable claim on whatever value the project eventually generates, whether that’s a grant, a support contract, or public infrastructure funding.

This isn’t speculative for me. GrowGood’s data model already records EconomicEvent rows with an effort_quantity_value field, separate from the resource a process produces, precisely so that labour is a tracked fact rather than an assumption buried in a payroll system somewhere else. We’ve pushed the same vocabulary further than most Valueflows implementations by extending it to non-human ecological agents, recording a mycorrhizal network’s phosphorus transfer or a hedgerow’s pollination service as an economic event with a stake-holding agent on each end. If the model can hold a fungal network as an agent with a recorded claim, it was never going to struggle with a documentation contributor.

How Contribution Accounting Actually Works

“Contribution accounting” isn’t just a phrase for “we wrote it down.” Sensorica, the Montreal open value network that forced Valueflows into existence, built the actual mechanism, and it’s worth walking through, because it answers the harder question: once every contribution is logged, how do you turn that into money without a payroll department deciding who deserves what?

Their system, NRP-CAS (Network Resource Planning, Contribution Accounting System), runs in two distinct phases. During the contribution phase, everything, hours, materials, money, expertise, is logged against the specific project it served, by whoever did it, at the time they did it. Nothing is estimated after the fact or reconstructed from memory at invoice time. Then, when a project actually generates revenue, a “value equation,” what Sensorica now calls a Benefit Redistribution Algorithm, converts the accumulated contribution log into shares of that income. Crucially, the formula is published before the work happens, not applied retroactively by whoever controls the bank account. Everyone contributing to a project can see, in advance, roughly how an hour of soldering will be weighted against an afternoon of documentation or a week of circuit design.

The output isn’t a wage. It’s closer to fluid equity: a proportional, ongoing claim on whatever the thing they built earns, for as long as it keeps earning, not a single invoice for a single job. A contributor who logs a bug report and a translated changelog in a project’s first month has the same standing, when revenue eventually arrives, as the one who wrote the module that made the sale. Nobody has to guess in advance whether their kind of contribution counts. It was designed to count from the start.

None of that works without a way to stop the ledger from being gamed, hours logged that didn’t happen, contributions padded to inflate a claim. Sensorica pairs the contribution log with a reputation system: a community-governed trust layer that filters who gets matched to which tasks and puts a check on inflated or low-quality logging, run by the network’s own participants rather than a platform operator sitting above them.

This is exactly the layer GrowGood’s EconomicEvent records are built to feed, once revenue-sharing agreements exist to consume them, though we haven’t built a Sensorica-style value equation on top of our own ledger yet. The accounting substrate and the distribution algorithm are separable problems, and getting the first one right, a truthful, granular record of who did what, is most of the work.

The Half That’s Still Missing

Leanne Ussher, who works alongside me on GrowGood, pushed back after reading a draft of this post. The objection is strong enough that it needs its own section rather than a caveat before the close.

Contribution accounting solves the supply side of this problem: given a pool of money, it fairly divides who gets what share, weighted by what they actually did. It has nothing to say about the demand side: why that pool exists at all, or how large it is, for a good that costs nothing to reproduce once it’s made (its marginal cost, the cost of producing one more copy, is close enough to zero not to matter). Leanne’s summary of the gap was blunt and correct: even a perfectly fair claim, 50% equity, in something priced at zero is still zero.

That’s not hypothetical for this post’s own central example. Sensorica’s NRP-CAS, the mechanism the previous section walks through, has been proven to distribute revenue fairly. But the revenue it distributes comes from selling physical sensors, lab instruments, and fabrication consulting, goods and services with real marginal costs, not from licensing the open hardware designs themselves, which cost nothing to copy. The mechanism is sound. It has only ever been tested on the easy case.

It’s an old problem wearing a new interface. Land, water, breathable air in a city, all of them had enormous fixed costs to make usable at scale, clearing, irrigation, sanitation, and were then effectively free once that cost was sunk. Every market economy hits the same fork at that point: leave the good abundant and non-excludable, open to anyone regardless of ability to pay, which is efficient but leaves nobody able to recoup what it cost to build, or enclose it, restrict access, and charge to recover the fixed cost, which is the same enclosure mechanism part one of this series describes, just applied to infrastructure instead of code.

Leanne’s sharper question is whether a contribution ledger has to be denominated in market price at all. Tie its claims to actual market revenue and you inherit the marginal-cost-to-zero problem for anything purely digital. Decouple the claims from market price, fund the pool some other way, a grant, a tax, a fixed community allocation, and the ledger can allocate shares of something that was never going to clear a market price in the first place. The state-mediated version of that decoupling is exactly what part two of this series already described: Sovereign Tech Fund-style public bodies, or the Caisse des Dépôts-backed EuroCommons programme, fund the fixed cost of digital infrastructure through non-market means, tax revenue, public mandate, precisely so the resulting good can stay free and non-excludable at the point of use. A state doesn’t need the ledger’s claims to clear a market price, because it isn’t selling the good. It’s provisioning it.

Leanne’s harder point is what happens without a state. Most digital commons projects are transnational, and no single government’s tax base captures enough of a global project’s diffuse benefit to justify funding all of it alone. Her proposed answer, sharpened in conversation after she read a draft of this post, is a bounded alternative: a community running an antirival, zero-marginal-cost network good, community WiFi or LoRaWAN towers, which get more valuable the more people use them, priced the way a tax works. Individual benefit exceeds individual cost, community loyalty makes non-payment unworkable rather than optional, and a monopoly issuer runs the arrangement for social good, routing the proceeds to open-source projects funded through contribution accounting. GrowGood, in her example, starts open and free, becomes valuable once it has market share as an antirival good in its own right, and only then does the governance body start asking for contributions back, the way large companies who depend on Linux eventually contribute changes upstream, which sets the pace at which maintainers can afford to offer support.

That’s not built, and I’m not going to pretend it’s solved. But none of its pieces are speculative. hAppenings Community C.I.C. has run an hREA-based mutual aid application, Requests & Offers, in alpha since July 2025, tracking exchanges of skills and resources between community members with no monetary transaction at all, built with direct technical guidance from Lynn Foster and Bob Haugen. And funding a commons project through something other than a grant or a donation already has precedent outside hREA entirely, though the precedents cut both ways. Bonfire, the federated ActivityPub project, moved from an NLnet grant that ended in early 2025 to peer crowdfunding on Open Collective once it had a v1.0 release, a lead Lynn Foster pointed to when this conversation kept going past the draft. Its crowdfunding has stayed modest rather than proving the model, which is itself the point: even a released product with an existing user base and a grant-funded head start doesn’t automatically pull in enough peer funding to run on. Grassroots Economics, Will Ruddick’s community-currency non-profit behind Kenya’s Sarafu Network, has a narrower but sturdier example: it runs a validator node for the Celo blockchain and uses the validator rewards to cover its users’ transaction fees, external funding for a specific, ongoing cost that isn’t a grant and isn’t a donation either. Neither is the community fund Leanne is describing. But between them, an antirival good that gets more valuable with use, the limits of peer funding even with a head start, and revenue from infrastructure participation covering a real running cost, they sketch the shape of the problem Leanne is naming, and one piece of a working answer to it. It’s evidence the vocabulary underneath this post can already represent contribution and claim without needing a market price to anchor them, and evidence that at least part of the money doesn’t have to come from a grant committee.

None of this makes the ledger this post describes wrong. It makes it necessary and not sufficient, and it was Leanne who forced that distinction into the open.

Pro Potentia: Paying for the Future, Not the Past

Martin, reading a draft of this section, agreed with the marginal-cost diagnosis and then reframed what the ledger above is actually pricing, in a way that answers a fair worry rather than dodging it: if funding only ever looks forward, why would anyone sink years of unpaid, uncertain labour into building something in the first place?

The instinct, once money enters a commons, is to treat it as a reward for past deeds: here is a record of what happened, now here is a proportional share. Sensorica’s Benefit Redistribution Algorithm, walked through two sections back, works exactly that way, and where there’s real revenue to divide, sensors sold, instruments shipped, consulting invoiced, it should keep working that way. The ledger can price the past there because an actual sale generated an actual price to divide. Leanne’s gap is narrower than the whole problem: it’s the case where there’s no revenue at all, because the good is purely digital and costs nothing to reproduce. 50% equity in something priced at zero is still zero, as she put it above.

Martin’s reframe answers that narrower case without discarding the ledger the rest of this post has been building toward. What a payer is buying, when there’s no unit left to price, isn’t a slice of the past. It’s a bet on the future: more of what they want built next, by someone with a demonstrated record of building it well. That record isn’t manufactured from nothing. It’s exactly what the ledger accumulates: years of logged, checkable delivery, hours, translations, diagnosed bugs, documentation, that a payer can actually look at before handing over money. The person who spent five years maintaining a project unpaid isn’t erased by this reframe. In the ordinary case, they’re exactly who the ledger shows has the strongest, most credible claim on being funded next, because they built the track record the whole model runs on. This is what would actually have helped Mark Qvist, from two sections back: not a share of Reticulum’s non-existent sale price, a mesh protocol doesn’t have one, but a funder willing to back a decade of shipping it, while he was still the one shipping it. Funding pro potentia doesn’t stop rewarding the past. It’s how the past gets rewarded once there’s no sale to split it by: not as a lump sum for a finished unit of work, but as an ongoing, compounding claim on future funding that has to keep being re-earned by continuing to deliver.

That does cut both ways, and Martin was candid about the edge rather than smoothing over it. Reputation isn’t tenure. If a newer contributor is demonstrably better placed to serve a project’s users right now than a longtime maintainer, funding pro potentia can route toward the newer contributor, and that will occasionally bruise an ego that assumed years of service should settle the question on its own. That’s a real cost, worth naming rather than pretending the model is only ever comfortable. But it’s the exception the model has to tolerate, not the rule it runs on. The ordinary case is that sustained delivery is exactly what builds the reputation nothing else can substitute for, which is the strongest answer this post has to the question of why anyone should bother.

The mechanism question resolves the same way. Sensorica’s NRP-CAS is one specific formula for dividing revenue by logged contribution. Martin’s point is that no commons needs that specific formula, or any specific formula, for funding pro potentia to work once there’s no revenue left to divide. What it needs is a reputation point, a person, a project, a government agency, trusted enough, on the strength of its recorded history, to reliably move in the direction its payers want. What happens inside that point, how it distributes further inward, is exactly the membrane’s job from two sections back, and it should stay inside it. Micro-managing that internal distribution from the outside is its own mistake: ordinary payers don’t have the attention to track many fine-grained reputational ledgers at once, any more than a customer tracks how a tradesperson splits an invoice with an apprentice. One trustworthy point of contact, backed by a real record, is the entire interface a payer needs.

None of that requires the corruption question answered first, and Martin’s blunter version of that point is worth keeping intact: we are collectively too shy about just paying someone with a track record, asking more questions than we need to in order to guard against a corruption that, in practice, rarely turns up.

Closing the Loop on the Series

This ties back to both of the earlier posts more than I expected when I started writing it. Part one described the expropriation: decades of uncompensated human labour, Wikipedia edits, OpenStreetMap contributions, forum answers, absorbed as AI training input with no mechanism to trace or compensate it. Part three named the same gap from the infrastructure side, in the knowledge layer of the AI stack, where commons-based peer production goes ungoverned and unfunded, benchmarks rot, and nobody’s contribution is tracked well enough to reward.

Contributory accounting is the missing layer underneath both diagnoses, and, as the previous section lays out, only half of what’s missing: it doesn’t, by itself, produce the money. Sovereign Tech Fund-style public bodies, of the kind covered in part two, a fixed community fund of the kind Leanne describes above, or something like the Digital Commons Trust structure I’ve sketched previously for projects like Reticulum, still have to be the ones willing to route real money through it. But without a ledger that records contribution honestly, in whatever form it takes, any money that does show up ends up distributed the same way it always has: to whoever’s name is easiest to find, usually the person who happened to write the code.

None of this is finished thinking. hREA implementations are still early, mostly running in small cooperative and open-value-network contexts rather than anything at Wikipedia’s or the Linux kernel’s scale, and getting a funding body to route money through a claims ledger instead of a grant committee’s judgement is a governance fight in its own right. But Martin was right that this was the gap, and right that it was ideological before it was technical. Leanne was right that the ledger only ever answers half of it. And Martin was right again that even the half it does answer works differently once there’s no sale left to divide: the past isn’t discounted, it’s what earns the claim on what comes next. Three parts became 3+1 because that argument named a real gap, and a series about the commons should probably practise what it argues for: crediting the labour that improved it, even when that labour showed up as a reply on Mastodon rather than a pull request, or as pushback on a draft before it shipped.

Thanks to Martin Owens for the argument that started this post, for the conversation that shaped it along the way, and for proof-reading it. Read Martin’s post on Mastodon →

The +1. This wasn’t part of the original plan; a Mastodon comment from Martin on What the Commons Built (And What's Taking It Apart) made the gap too specific to leave in a reply thread. Previously in the series: What the Commons Built (And What's Taking It Apart) on the history of digital commons enclosure, Europe Chose Differently on what France and Germany are doing about it, and The AI Stack Needs a Commons Governor on governing the AI stack as a commons.

Sources

Free software’s founding trade-off

  • Stallman, R. Free as in freedom, not free as in beer: the GNU Project’s foundational distinction, permitting commercial redistribution while building no corresponding claim on compensation for contribution
  • Raymond, E.S. (1998). Homesteading the Noosphere. Later collected in The Cathedral and the Bazaar (1999), O’Reilly: the reputation-economy account of hacker culture, explicit that it is positioned against an exchange economy

The cost of unpaid maintenance

  • Eghbal, N. (2016). Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation
  • Qvist, M. (2025). Carrier Switch. unsigned.io: the Reticulum maintainer’s account of stepping back from active development due to burnout and unsustainable unpaid labour
  • Apache Software Foundation (2021). Security advisory, CVE-2021-44228 (Log4Shell): the scale of consequence when critical, widely-depended-on infrastructure is maintained by a small volunteer team
  • xkcd #2347, “Dependency”: the cultural shorthand for the same pattern

REA, Valueflows, and hREA

  • McCarthy, W.E. (1982). The REA accounting model: A generalized framework for accounting systems in a shared data environment. The Accounting Review, 57(3): 554–578
  • Valueflows: valueflo.ws: the open vocabulary extending REA to multi-party, distributed economic coordination, developed by Lynn Foster, Bob Haugen, and the ValueFlows community
  • Sensorica: sensorica.co: the Montreal-based open value network operating since 2011, whose contributory accounting needs drove much of the early development of the Valueflows vocabulary. The NRP-CAS ledger described in this post ran at nrp.sensorica.co; that server has since been retired as Sensorica moves the model to a peer-to-peer Holochain successor, preserved at the Wayback Machine
  • Valueflows, Value Equations: the vocabulary’s own treatment of value equations and Benefit Redistribution Algorithms, the mechanism that converts a logged contribution into a share of realised revenue
  • P2P Foundation Wiki, Open Value Network and Sensorica: reference descriptions of the OVN model, NRP-CAS, and the fluid-equity approach to distributing income by contribution
  • hREA: github.com/h-REA/hREA: the agent-centric implementation of Valueflows on Holochain, requiring no central ledger authority

The demand side: price, public goods, and non-market alternatives

  • Samuelson, P.A. (1954). The Pure Theory of Public Expenditure. Review of Economics and Statistics, 36(4): 387–389: the foundational account of goods whose benefits can’t be confined to paying customers, and why markets underprovide them, the theoretical shape of the fixed-cost-versus-enclosure fork described above
  • Ostrom, E. (1990). Governing the Commons. Cambridge University Press (cited in full in part one): the same abundance-versus-recouping-fixed-cost tension her design principles for common-pool resources are built to manage
  • Pignot, S. (2025). Summer Alpha Test: Mutual Aid with hREA. hAppenings Community C.I.C.: the Requests & Offers hApp, an hREA-based mutual aid application tracking skill and resource exchange with no monetary transaction, in alpha since July 2025, built with technical guidance from Lynn Foster and Bob Haugen
  • Grassroots Economics: grassrootseconomics.org, Ruddick, W.: the Sarafu Network’s arrangement as a Celo validator, using validator rewards to cover users’ transaction fees rather than relying on grants or donations. See also Firm Behind Sarafu Network Moves to Celo Blockchain, Kenyan Wallstreet, and Celo Staking Rewards, Grassroots Economics
  • Bonfire: bonfirenetworks.org, the federated ActivityPub project’s shift from an NLnet grant, which ended in February 2025, to peer crowdfunding via Open Collective after its v1.0 release; as of March 2026 its Open Collective budget remains modest, illustrating how hard peer funding is even with a grant-funded head start

Related reading on this site

  • Open Source Is The Hope, But It Needs Our Help: the Reticulum story in full, and the existing (patronage-based) tools for supporting open-source maintainers
  • GrowGood: growgood.org.au, the open-source farm management platform referenced throughout this post, built on the Valueflows/REA data model described here
←Nature Is Not a Cash Flow: The Mismatch of Conservation and Private Finance

Webmentions

What's this?

❤️ Liked by 1 person

Want to comment? Reply to this post from your Mastodon/Fediverse account, or mention this post's URL in your reply. Your comment will appear here automatically!

Have your own blog? Send a webmention to https://webmention.io/gaggl.com/webmention