Exclosure

Description

Victor:

"An exclosure is a fenced plot that keeps grazers out so the land inside can recover. Nobody is confined. The fence points the other way. And the plot does something specific: it works as a reference. You walk past it and see what the whole landscape would look like if the pressure were removed.

I think exclosure is the word for what commons should be doing now, and I think a specific technological shift makes it possible to do it in a way that wins.

Enclosure fences a shared resource in so it can be extracted. Exclosure fences market logic out so a set of relations can regenerate: attention that isn’t monetized, labor that isn’t priced, data that isn’t harvested, care that isn’t a service.

This reframes the competition. Commons don’t beat the market on price or scale, and they shouldn’t try. The competition is over territory of social relations. An exclosure wins locally by removing the grazer, not by grazing better. Then it does what refugia always do in a recovering landscape: it becomes the seed source. Practices propagate outward from the protected patch."

(https://liminalcommons.substack.com/p/progressive-exclosure-14f)

Discussion

How to do Exclosure: Inference as a Service

Victor:

"Inference as a service makes functionality generatable on demand at near-zero marginal cost. A form, a tracker, a scheduler, a ledger, a governance tool: things that once needed a vendor, a roadmap, and a pricing page can now be produced by the people who need them, in the shape they need, in an afternoon.

The firm stops being the necessary organ for making tools. A commons can build its own.

That single shift closes the gap that commons have never been able to close, and it opens a vector that the defensive literature on AI and commons has mostly missed. Almost everything written about AI and the commons is about protecting commons from AI, or governing AI as a commons. Both matter. But the more interesting move is using inference to let commons out-produce the market and reverse enclosure function by function."

More details on Inference as a Service

More explanation by ChatGPT, prompted by Michel Bauwens:

In this essay, “inference as a service” is essentially a deliberately provocative way of saying: AI inference turns the production of software functionality into something that can be generated on demand, rather than something that has to be purchased from a firm.

1. What is “inference”?

Here, inference means the computational process by which an AI model takes an input or request and generates an output.

For example, instead of buying a piece of software called “membership management system,” you could tell an AI:

“Build me a simple system for tracking members, their contributions, and whether they have participated in the last three meetings.”

The model generates the relevant code, database structure, interface, etc. The important thing is that the functionality is produced when you need it.

That is why the author says:

“Inference as a service makes functionality generatable on demand at near-zero marginal cost.”

The key word is functionality. The argument isn't really about AI chatbots as such. It is about AI making the production of tools cheap and immediate.

2. Why call it “as a service”?

There is an interesting tension in the phrase.

Normally, “X as a service” means that you don't own X—you rent access to it from a provider. Software-as-a-Service (SaaS), for example, means that instead of owning and maintaining software yourself, you pay a company to provide it.

So “inference as a service” initially sounds like another form of dependence on a firm: you send your request to OpenAI, Anthropic, etc., and they provide the computational inference.

But the author is interested in what happens because inference has become so cheap and powerful, not necessarily in the current commercial form of the service.

The crucial distinction is between:

the service as a product

→ “Here is a piece of software we have built; pay us to use it.”

and

inference as a productive capacity

→ “Tell the system what you need, and it can generate the functionality for you.”

The latter potentially undermines the economic reason for buying software from firms in the first place.

3. Why does this matter for commons?

This is where the argument becomes much more interesting.

The author claims that commons have historically had a problem: they can steward things collectively, but they have difficulty producing new tools and infrastructure.

A commons might collectively manage land, knowledge, trust, care, or a community—but if it needs:

1. a database,
2. a scheduling system,
3. accounting software,
4. a membership system,
5. a governance platform,

it usually has to buy those things from the market.

Hence the striking observation that many supposedly autonomous commons run on Slack, Notion, Stripe, Google Workspace, etc. The social relations may be organized as a commons, but the technical infrastructure supporting those relations is commercially owned.

The author's claim is that AI changes this asymmetry.

If a commons can simply say:

“We need a tool that does this particular thing in this particular way”

and generate that tool itself, then it no longer necessarily needs a company to produce the tool.

So:

Before:

Commons → needs tool → buys tool from firm → market relation enters commons

With cheap inference:

Commons → needs tool → generates tool → maintains it collectively

That is what the author means by saying:

“The firm stops being the necessary organ for making tools. A commons can build its own.”

4. This is why “inference” is more important than “AI”

I think this distinction is important for understanding the argument.

The author isn't primarily saying:

AI will make humans more productive.

That's the usual AI argument.

They're saying something closer to:

AI potentially changes who or what needs to exist in order for productive capacities to be created.

Historically, if you wanted a piece of sophisticated software, you needed:

capital → programmers → firm → product → customer

The firm was necessary because software production was expensive and specialized.

If inference makes the generation of relatively specialized functionality extremely cheap, then that chain potentially becomes:

need → inference → functionality

And that is potentially a very significant change in the organization of production.

This explains the rather strong statement in the essay:

“The firm was the price of building; that price just went to zero.”

I'd qualify that claim heavily—the cost of building certainly hasn't literally gone to zero—but that is the theoretical wager.

5. Why does this produce “exclosure”?

Now we can understand the larger argument.

The author distinguishes enclosure from exclosure.

Traditional Enclosure:

common resource → fence it off → make it privately exploitable → market enters.

Exclosure reverses the direction:

commons → exclude market relations → allow alternative relations to develop.

An AI-generated tool supposedly makes it possible to perform this exclusion one function at a time."

Towards a Strategy of Progressive Exclosure

Victor:

"The fence doesn’t go up all at once. That’s the difference between exclosure and exit. No commune, no fork, no purity test at the gate. Market logic is excluded relation by relation, in sequence, so the plot keeps functioning while it recovers.

The sequence matters more than the endpoint. Exclude first what recovers fastest and costs least to protect: internal tooling, documentation, the glue. Then what needs recovered soil to survive: coordination, membership, decision records. Then the economic layer: accounting, contribution ledgers, exchange. And last, the hardest thing to hold without the market’s scaffolding, which is inference itself, fenced out through pooled compute, federated hosting, and open-weight models as they mature.

Each stage is the substrate for the next. Try to exclude the last thing first and you get the familiar failure: a livelihood commons with no relational ground under it, collapsing back into a nonprofit or a startup with better vocabulary.

Three properties fall out of doing it this way:

• Reversible boundaries. The fence is moved, not built. Each extension is a hypothesis about what can regenerate here now, and it can be pulled back without abandoning the plot.

• Gradients, not walls. Some market pressure at the edge is tolerable, even useful. It keeps the exclosure legible to people outside it and it’s how the plot recruits. Fully sealed plots stop propagating.

• Timing by recovery, not conviction. Extend the fence when the last excluded relation is visibly regenerating, not when you feel ready ideologically.

Every function a commons generates for itself does three things at once. It stops a recurring extraction: a subscription not renewed, a platform take not paid. It produces a tool that fits the commons better than the product built for everyone. And because it was built inside the fence, it encodes the commons’ logic by default, with no lock-in, no dark patterns, no upsell, and it propagates as a commons artifact that other commons can adopt.

• Substitution, fit, and seeding, from one cheap act. Repeat.

The pressure is asymmetric. The market has to keep selling. The commons only has to stop renewing. Each substitution shrinks the market’s territory and lowers the cost of the next substitution, because the generated tools are themselves reusable inputs. The market can respond by cutting price. It cannot respond by becoming non-extractive without ceasing to be a market.

And the market’s last defensible ground, maintenance, reliability, continuity, the boring work of keeping things running, is precisely the ground commons are natively good at. Generation is cheap; stewardship isn’t. The winning combination is generation from inference plus maintenance from the commons. That’s a division of labor the market can’t replicate without becoming one.

Where it breaks

This is directional, not self-executing. Three failure modes, none theoretical:

Tools outrun care. Generation is so cheap that the commons drowns in unmaintained software. The ratchet slips.

Inference stays owned. Open models never catch up, the root grazer is never fenced out, and every “exclosure” is really a tenancy.

The fence turns toward people. The tooling becomes a moat, the exclosure becomes an enclosure, and you’ve built a firm with a philosophy.

What makes the dynamic hold is a commons that treats generation as easy and stewardship as the actual work, and moves the fence only as fast as recovery allows.

Succession, not revolution

This is inevitable the way ecological succession is inevitable. Given the substrate and no catastrophic disturbance, this is what grows. The disturbances are the whole game.

Enclosure had its own gradualism: a field here, an act of Parliament there, three centuries of it. Progressive exclosure is that gradualism run in reverse. A commons can become strictly more excluded of market logic every year while never having to declare itself a rupture. It just keeps moving the fence.

Progressive exclosure, compressed

Victor:

• The market wins by producing, not by allocating. Commons steward well; they’ve never built well.

• Inference makes production free. The firm was the price of building; that price just went to zero.

• Enclosure fenced the commons in. Exclosure fences the market out.

• Fence one relation at a time: tools, then coordination, then economy, then inference itself.

• Every self-made tool substitutes, fits, and seeds. Three gains, one act. Repeat.

• The market must keep selling. The commons only has to stop renewing. That asymmetry is the ratchet.

• What the market keeps, maintenance and continuity, is the commons’ native ground.

• Generate cheaply. Steward seriously. Move the fence as fast as recovery allows.

• It fails if tools outrun care, if inference stays owned, or if the fence turns toward people.

• Succession, not revolution. Given the substrate, this is what grows."