Who owns the stone?

The Foundation's page on the Harvest Model© describes the last step in one sentence: "We extract those proven components, standardize them, and release them as the open 7 Nexi infrastructure." I have said versions of that sentence on stages and in conversations for most of this year. It is a good sentence for a portal. It is also the place where every serious question about the model hides, because the verb does five jobs at once.

The companion essay, We don't build cathedrals, argues for the order of operations: a real problem under real load first, the shared component lifted out afterwards. This essay starts where that one stops, at the moment of lifting. A venture has built something that works. Other ventures, and eventually people and agents outside the programme, could use it. What exactly happens next, and who decides?

My answer, worked out over the last months of planning, is that "harvest" names an agreement, and the agreement has five separate subjects. Merge any two of them and the model fails in a way that has already happened, more than once, to infrastructure far larger than ours.

I. One verb, five relationships

Take a single component: say, the piece of a venture's product that checks who is allowed to see which evidence. When I say it is harvested, I am making five claims, and each has a different counterparty.

Contribution. Someone decides to offer the component to the shared layer. That decision belongs to the venture that built it, because the venture knows what the component costs to separate from its product and what it gives away by doing so.

Ownership. Someone holds the rights in the code, the name and the design. Contribution does not settle this. A venture can contribute a component and keep the rights, license them, or transfer them, and each choice changes what its own investors are holding.

Use rights. Someone else may use the component, under terms. Free for development and testing is one set of terms. Free in production for anyone is another. Use by a competitor of the contributing venture is a third, and the one most often forgotten until it happens.

Maintenance. Someone fixes it when it breaks, answers the security report at night, and keeps it compatible with what changes around it. Maintenance is a cost that never ends and is almost never priced at the moment of contribution, because at that moment the component works.

Operation. Someone runs it for people who depend on it, with an uptime they can hold someone to, and bills for that. Operation is a business. Use rights say what you are allowed to do; operation says who keeps the lights on while you do it.

Five relationships, five decisions. The single verb on the portal compresses all of them into one gesture by one actor, and that compression is exactly what lets infrastructure rot.

II. What breaks when they merge

The history of shared software is mostly a history of these five being merged by default and pulled apart after a failure.

Use without maintenance. In April 2014 the Heartbleed bug was disclosed in OpenSSL, the library that secured a large share of the encrypted traffic on the web. Use was universal and free. Maintenance rested on one full-time developer and a handful of volunteers; outright donations, by the project's own public account at the time, came to about two thousand dollars a year. The Linux Foundation launched its Core Infrastructure Initiative weeks later to fund exactly the relationship that nobody had agreed to carry. The code had been contributed and was used everywhere. Its maintenance had never been assigned.

Ownership by default. The opposite failure is quieter. A shared programme that treats "harvest" as "the centre takes it" turns every contribution into a transfer. The venture's investors see an asset leave the company for nothing, so the venture stops contributing, and the shared layer stays empty. A harvest that confiscates produces a cathedral by another route: an institution that owns a drawing of the infrastructure it hoped to receive.

Use confused with operation. "Free and open" is a statement about rights. It says nothing about who pays to run a production service with a pager attached. When the two are merged, one of two things happens: the free tier quietly becomes the production service and is run on goodwill until it fails, or the operator restricts the rights to protect the business and the openness was a phase.

There is a well-known case where the five were pulled apart deliberately, and it is instructive because of its scale. In 2015 Google contributed Kubernetes to the newly founded Cloud Native Computing Foundation. The contribution was Google's decision. The trademark is held by a neutral foundation. The licence let anyone use the code, competitors included. Maintenance became the work of contributors from many companies under a public governance. And operation became a market: Google, and its competitors, sell managed Kubernetes as a paid service. Five relationships, five different holders. That separation is a large part of why the project became shared infrastructure instead of one company's product with a public repository.

III. How the Program separates them

The Fucina Nexus Program writes the separation into its plan, and I want to state its principles plainly, because they are what an essay like this one must not blur.

A harvest is a specific agreement. The plan defines Harvest as an approach for obtaining reusable subsystems through specific agreements. Each subsystem gets its own. There is no general clause by which joining the programme hands over what a venture builds.

Contribution is a possibility, never a quota. A venture may contribute zero components or several, across several of the seven Nexi. A venture that contributes nothing has not failed the programme; its first job is its own product.

The five decisions are taken separately. Contribution, ownership, use rights, maintenance and commercial operation are recorded as distinct decisions. Agreeing to one does not imply the others.

Use for building is free; operation is paid. Itabyrium is the shared infrastructure the Foundation offers free of charge, and in this phase it supports the ventures in development and testing. When a venture's workload becomes an operational commercial one, it is meant to move to Samarcanda, planned as the paid, production-grade service for the same kind of infrastructure: for the ventures first, and later for external businesses as well. Accepting a venture's proof of concept does not, by itself, turn it into a commercial operation.

The Foundation cannot buy the stone. The Foundation neither invests in ventures nor receives investment; investment in ventures comes from external funds, among them Fininverse, which is in formation, and there is no programme capital pool. I count this among the most useful constraints we have. An institution that cannot pay for components with equity has to obtain them by an agreement the contributing venture actually wants. The confiscating harvest of the previous section is closed to it by construction.

I should be exact about where this stands today. These are principles in a plan. The ventures are building their first proofs of concept, with acceptance dates running through November 2026. No component has yet been harvested under such an agreement, and I am making no claim here about any venture's results.

IV. What I am still testing

I publish this as a hypothesis because three questions remain open, and I would rather name them than let the verb cover them again.

Who maintains after the harvest. The OpenSSL lesson says maintenance must be assigned, with its cost, at the moment of contribution. I do not yet know the right default: the contributing venture, paid for the service; a maintainer group across ventures; or the operator, folded into the price of operation. My working guess is that the answer differs by Nexus, and that an agreement which leaves the line empty should not be signed.

Whether ventures will want to contribute. The argument for contributing is a compounding effect: a component used by several ventures is tested by several loads, and every venture gets back more than it gave. That is an argument; it has to survive a venture's board, with its own investors at the table. The first agreements will tell us whether it does.

Where free ends. The line between development use and operational use is clear in a plan and blurry in a real workload. A test environment that a customer starts depending on has crossed it without anyone deciding. The agreement has to say who notices and what happens next.

A cathedral is built by guilds that know which stone is whose, who carves it, who repairs it and who opens the doors on Sunday. Our word for the whole of that is harvest, and it has to carry all five answers before it means anything.

Harvest is an agreement with five parts, and we intend to write every one of them down.

The forge is lit.
Ex Fucina, Nexus.