FOLIO: How Many Grapes Went into the Wine?

Operational enclosure, ecosystem enclosure, and what we owe each other in open source

Ian Ibbotson

With apologies and deepest respect to Stafford Beer for appropriating the title How Many Grapes Went into the Wine: Stafford Beer on the Art and Science of Holistic Management.

FOLIO is open source.

That statement is true. Its software is published under open-source licences. Libraries, developers and suppliers can inspect the code, modify it and—in principle—run it for themselves.

But a licence answers only one part of the question.

From the point of view of a developer trying to run the complete system, a consortium considering independent operation, or a specialist organisation trying to sustain applications it has contributed, a more demanding question appears:

Can a competent independent organisation take the publicly available source, artefacts and documentation and not merely deploy the complete system today, but sustain it over years—adopting new releases, replacing staff, recovering from failure, preserving institutional knowledge and continuing to operate without privileged assistance?

A one-off installation is not enough. The organisation must be able to remain competent as the software changes and as people come and go. A new member of staff should be able to learn the system from public materials rather than inherited folklore. Upgrades should not repeatedly require rescue from the original host. Operational knowledge should live in maintained tooling and documentation, not only in a few unusually experienced individuals.

The freedom to run is not meaningful if it lasts only as long as one person remains in post.

Nor is that freedom established by pointing to GitHub, observing that several organisations contribute code, or showing that somebody has successfully self-hosted FOLIO with substantial help from an organisation that already possessed the necessary operational knowledge. Those facts matter, but they do not demonstrate that the freedom to operate is practical, reproducible and shared.

Operational enclosure

I have come to think of this gap as operational enclosure.

Operational enclosure occurs when software remains legally open, but the practical ability to build, deploy, operate, upgrade, integrate and leave becomes concentrated in a small number of organisations.

This is not an argument that complex software must be easy. FOLIO is a substantial distributed system. Running it will always require professional skill. The relevant distinction is between complexity and dependency.

Can the required expertise be acquired from public, maintained and coherent materials? Or does successful operation depend on accumulated knowledge held inside particular hosting providers?

FOLIO has public Snapshot environments. The project’s own developer documentation describes them as reference environments used for integration and verification.¹ But this exposes an important distinction between a reference installation and a reproducible reference deployment.

A reference installation proves that somebody was able to run the system. It does not prove that an independent contributor, library, consortium or alternative provider can reproduce what they did.

If a public environment is assembled and operated using a provider’s private deployment definitions, cloud architecture and operational practice, the public can inspect the result without necessarily being able to recreate it. In that case, the installation demonstrates the operator’s competence—not that the wider community possesses the same capability. Where the operator also sells hosted FOLIO, the environment risks functioning more as a showroom than as shared operational infrastructure.

The stronger tests are these:

Is there a coherent, maintained deployment corresponding to each release?
Can an ordinary contributor run the complete stack from public materials?
Are the deployment definitions themselves published, versioned and maintained?
Are upgrades tested against that deployment?
Are observability, backup, recovery and migration part of the public operating model?
Can a new team member learn to operate it without access to private vendor knowledge?
Can the result be reproduced without dependence on one provider’s proprietary cloud configuration?

A reference deployment need not be the only valid production architecture, nor should it pretend that operating FOLIO is a one-click exercise. It should be complete, maintained, reproducible and independent of privileged knowledge. It should support continuity: training new staff, validating future releases, rehearsing upgrades and preserving competence beyond the tenure of any one individual.

That makes a reproducible reference deployment more than useful documentation. It is evidence that the freedom to run is real.

It is also part of the remedy. Maintaining it would return architecture, release assembly, configuration, deployment, upgrade and recovery knowledge to the commons instead of allowing those capabilities to accumulate privately inside hosting organisations.

At minimum, participants in an open ecosystem owe each other a coherent public account of how the supposedly open system can actually be run.

From operational enclosure to ecosystem enclosure

Operational enclosure does not remain a technical inconvenience. It changes the structure of the market and community around the software.

When independent operation becomes difficult or exceptional, libraries converge on providers that already possess the necessary knowledge. Those providers gain recurring revenue, implementation experience, customer relationships and influence over future development. A reinforcing cycle develops:

Independent operation is difficult.
Libraries converge on established hosts.
Hosts accumulate revenue and operational knowledge.
Revenue buys development capacity and influence.
Independent creators become increasingly dependent on hosts for funded work.
Product and architectural choices increasingly reflect the needs of dominant hosts.
Independent operation becomes harder still.

This is ecosystem enclosure.

A platform may remain technically distributed and legally open while funding, expertise, integrations, customer access and strategic direction consolidate around a small number of commercial centres.

Libraries turned towards open source partly because they had seen what repeated consolidation did to the library-management market. FOLIO promised something different: modularity, collaboration, shared ownership and freedom from dependence on a proprietary monolith.

The uncomfortable possibility is that we may reproduce the outcomes of that monolith without reproducing its legal form.

The monolith may no longer be in the source tree. It may now exist in the business model.

A genuine ecosystem also requires operational substitutability and capability continuity.

Operational substitutability means that one provider can be replaced by another. Capability continuity means that the knowledge required to operate the system survives staff turnover, organisational change and the passage of time.

It is not enough for several organisations to advertise FOLIO services if they ultimately depend on the same private body of knowledge or deployment architecture. An ecosystem is not diverse merely because it contains many organisations. It is diverse when important functions are independently reproducible across them.

A useful test of provider plurality is therefore:

Can one provider be replaced by another without reconstructing missing operational knowledge from first principles—and can an organisation replace one competent staff member with another without losing the ability to operate the system?

If not, what looks like diversity may be closer to a monoculture with multiple storefronts.

A reproducible reference deployment is therefore not merely a self-hosting convenience. It is the seed stock of operational diversity. Without one, provider plurality is an assertion. With one, it becomes testable.

An ecosystem is made of relationships

We are good at naming the actors in an open-source ecosystem: libraries, developers, maintainers, specialist product organisations, foundations, integrators and hosting providers.

But an ecosystem is not simply a list of participants. It is a set of relationships, dependencies and reciprocal obligations.

Who funds whom? Who carries maintenance risk? Who captures recurring revenue? Who contributes intellectual property? Who can leave? Who has the power to set terms? Who is responsible when a specialist creator disappears and the product knowledge embedded in that organisation disappears with it?

Much of the current narrative is one-directional. Creators contribute. Libraries benefit. Hosting providers commercialise. Governance institutions celebrate openness.

The question too often left as a footnote—and one I have repeatedly put to the OLF without receiving a substantive reply—is:

What do we owe each other?

Libraries may reasonably believe they are sustaining open source because they have selected FOLIO and pay a substantial annual fee for the service. But most dependable revenue enters through the hosting relationship. Unless a library asks how that money is allocated, it cannot know whether it is sustaining shared software, maintainers, specialist creators and common operational infrastructure—or merely the company operating its instance.

Paying for a hosted open-source service is not automatically the same as sustaining the open-source commons. The hosting contract can become a fig leaf for stewardship.

The reciprocity gap

Hosting is legitimate and valuable work. Secure and reliable operation, customer support, upgrades and commercial risk deserve payment.

The problem is not that money changes hands at the hosting layer. It is that hosting has become the principal pinch point at which recurring revenue enters the ecosystem, while little in the prevailing model ensures that this revenue travels back through the chain that produced the value being hosted.

A healthy ecosystem depends on more than server operation. It depends on domain understanding, product design, implementation, maintenance, architectural memory, integrations, documentation, release engineering, deployment tooling and long-term care.

If those upstream capabilities are treated as free inputs, the host may remain sustainable while the ecosystem is progressively hollowed out.

This creates a perverse incentive. A responsible host that includes meaningful upstream maintenance and creator funding in its prices may appear more expensive than a host that treats the commons as a cost-free resource. The provider most committed to sustaining the commons can therefore be placed at a commercial disadvantage to the provider most willing to externalise its costs.

That is the important free-rider problem here. The issue is not that a company makes commercial use of Apache-licensed software; the licence permits that. The issue arises when a recurring business depends on other people continuing to absorb the costs of creation, maintenance and shared infrastructure, while excluding those costs from its own commercial model.

Legal permission to extract value is not the same as a healthy norm of reciprocity.

How many grapes went into the wine?

A hosted FOLIO service compresses a large and diverse chain of contribution into a single commercial transaction.

The library receives one invoice. That invoice may cover infrastructure, support, upgrades, service management and commercial risk. But it sits downstream of years of domain research, workflow design, product management, architecture, implementation, testing, security maintenance, release engineering, documentation and community participation.

The customer buys the wine. The price does not reveal which grapes are being replenished.

This is value-chain opacity: a complex chain of contribution is compressed into one downstream payment, leaving the customer unable to see which upstream capabilities that payment actually sustains.

Libraries may believe that paying for FOLIO sustains FOLIO. Hosts may regard common maintenance as the community’s responsibility. Foundations may regard institutional continuity as evidence that the ecosystem is healthy. Funders often prefer visible new features.

Meanwhile, the mechanical work that keeps the software real can remain unfunded.

Maintenance is not an optional afterthought

Open communities are often willing to fund new feature development and much less willing to fund maintenance.

Features are visible. They can be announced, demonstrated, attributed to a funder and described as a completed project. Maintenance is continuous, preventative and often invisible when it succeeds.

Modern software depends on a moving chain of runtimes, frameworks, libraries, containers, databases, operating systems and infrastructure components. CVEs appear. Dependencies reach end of life. Compatibility breaks. Release pipelines decay. Documentation diverges from reality.

The absence of visible failure is not evidence that maintenance costs nothing. It is evidence that somebody has been doing the work.

Feature funding pays for change. Maintenance funding pays for continued truth: that the software still works, remains secure and can still be operated.

A healthy open-source ecosystem therefore needs a maintenance metabolism: a dependable flow of resources for vulnerability response, dependency renewal, regression testing, release engineering, documentation and operational validation.

A coherent reference deployment belongs inside that maintenance metabolism. It gives the community a shared place to prove that releases can be assembled, upgraded, secured, observed, backed up, restored and moved.

Without such a mechanism, everyone can believe that somebody else is funding the unglamorous work.

What is the foundation sustaining?

The Open Library Foundation describes itself as an independent not-for-profit created to ensure the availability, accessibility and sustainability of open-source and open-access projects for and by libraries. It says that it provides a “safe haven” for community output, separated from the needs and goals of any single contributor, user or affiliated party.²

The Foundation charges annual fees to institutional, sponsor and project members. Its current published institutional fee is $1,000 a year; project membership begins at $1,000 plus charges for selected services.³

That creates an important question:

What, specifically, is being sustained?

A foundation necessarily has operating costs. Governance, administration, legal structures, accounting, events, communications and project infrastructure are real work. The OLF also provides substantial formal structure around the projects it hosts. None of that is incidental.

The harder question is whether this structure is sufficiently attentive to the relationships that produce and maintain the software. Preserving repositories, licences and institutional continuity is not identical to preserving the capacity of specialist creators and maintainers to continue their work.

The published information explains membership and project services and makes financial statements available.²³ What remains difficult to see, from a creator’s perspective, is how the Foundation assesses whether the productive ecosystem is healthy: whether maintainers are viable, whether specialist knowledge is being lost, whether shared maintenance is funded, and whether creators believe the institution is acting as their steward as well as the software’s custodian.

This is not primarily a demand that membership fees be redistributed according to a particular formula. It is a request for the OLF and its library members to make creator sustainability an explicit object of governance rather than an assumed consequence of preserving the code.

Useful questions would include:

How does the Foundation gather and publish the experience of creators and maintainers?
Does it know which projects or specialist organisations are carrying unfunded maintenance risk?
What common operational infrastructure is being sustained?
Who maintains a reproducible reference deployment?
What action is taken when funded work, operational knowledge or influence becomes concentrated?
Do libraries understand whether their membership and hosting expenditure sustains creators as well as institutions and services?

A safe haven for software is valuable. But a healthy commons also needs a safe and sustainable place for the people and organisations that create it.

Trustworthy infrastructure requires responsive institutions

At WOLFcon 2025, Rosalyn Metz gave a keynote titled The Future of Open: Building Trustworthy Infrastructure in a Fragmented World.⁴

I found much in that framing compelling. Trust, reciprocity, collective action and sustainable infrastructure are exactly the right concerns. FOLIO also shows why those ideas must be tested against the lived relationships inside the ecosystem.

The problem is not an absence of structure. FOLIO and the OLF have an abundance of committees, processes, legal arrangements and governance mechanisms. The concern is whether those structures are protecting a sufficiently broad conception of sustainability—or whether they are better at preserving software and institutional continuity than at hearing and defending the creators on whom both depend.

Over the past two years, I have written substantively to the OLF board about creator sustainability, operational independence and commercial concentration. I have received functional acknowledgements, but no substantive response to the issues raised.

That silence matters because institutions shape incentives even when they do not intend particular outcomes. If creators disappear while their code remains safely held and available, the Foundation may become more important as custodian at the same moment the productive community becomes weaker. That is not an allegation of design or bad faith. It is an institutional risk that deserves conscious scrutiny.

A foundation that accepts collective rights and legitimacy from creators therefore has responsibilities beyond procedural neutrality. It should ask whether creators experience the institution as a source of support and representation, whether libraries care about that experience, and whether the ecosystem’s formal structures are preserving reciprocal relationships rather than only durable assets.

Without that active stewardship, an open-source foundation can unintentionally become a legitimating layer through which an increasingly enclosed commercial ecosystem acquires the moral authority of a commons.

That is where open washing becomes a real risk—not because the licence is false, but because the truth of the licence can obscure the weakening of the relationships and productive capacity around it.

Libraries are not merely customers

Libraries are not powerless in this system. They choose providers, approve contracts, pay membership and hosting fees, appoint representatives to governance bodies and can demand transparency.

A library cannot assume that because it pays for FOLIO, FOLIO is being sustained.

It should ask its host what proportion of the fee funds shared product development, upstream maintenance, common deployment tooling and independent creators. It should ask whether the provider contributes to a reproducible reference deployment, whether configuration and data are portable, and what happens if the library chooses another host.

It should ask the OLF how institutional fees sustain the ecosystem rather than only the institution. It should ask where maintenance appears in the cost model: who carries day-to-day responsibility for existing applications, what funds release engineering and integration, and whether maintenance is treated as recurring infrastructure or left to intermittent feature projects and goodwill.

At first, libraries may reasonably assume that paying into an open-source ecosystem sustains it. Once the distinction between hosting revenue and commons funding becomes visible, continued indifference is harder to defend.

Stewardship cannot be outsourced merely by purchasing from a company that hosts open-source software.

A practical place to begin

The problems described here are large, but one practical intervention would expose and begin to reverse several of them:

Maintain a coherent, complete, public and reproducible reference deployment for FOLIO.

A Snapshot or demonstration instance is not enough. The community must be able to reproduce the installation, not merely visit it.

Make it possible for a developer to run the full stack. Publish and maintain the deployment definitions with each release. Test upgrades against them. Include observability, backup, restore, migration and realistic operational guidance. Ensure that the result does not depend on private infrastructure definitions or a single provider’s proprietary cloud architecture.

This would not solve creator funding or governance concentration. But it would establish a public operational baseline, return vital knowledge to the commons and create a concrete capability around which ongoing maintenance could be funded.

It would also reveal whether the ecosystem possesses genuine functional redundancy. If only one organisation can keep the reference deployment current, the community has identified a dependency rather than solved it.

Our Foundry work is one attempt to respond to this challenge: making deployment reproducible, making operational assumptions explicit, and making applications such as Agreements, Licences, Serials, Open Access and resource sharing usable beyond a single FOLIO platform or hosting model.

A module is not genuinely modular merely because its repository is separate. It is modular when it can be independently deployed, integrated and substituted.

The aim is not to remove hosting from the value chain. It is to prevent hosting from enclosing the value chain.

Repairing the broken relationship

There is a further conclusion I want to put on the table, although it deserves fuller treatment in its own right.

Open source did not thrive only because licences permitted reuse. It also depended on norms: libraries funded development, developers listened to libraries, contributors maintained what they had created, and all sides understood that the relationship carried obligations the licence did not spell out.

Hosting providers have partly disintermediated that relationship.

The library now pays the host. The host controls the customer relationship and recurring revenue. The creator may remain responsible for the software’s quality, security, maintenance and future, but no longer has a dependable economic relationship with the library benefiting from that work.

When norms are strong, a permissive licence can sit inside a reciprocal ecosystem. When those norms weaken, the same licence can enable a one-directional transfer of value.

That is why I am increasingly interested in the Functional Source License.

FSL is not an OSI-approved open-source licence. It is a Fair Source licence that permits broad use while restricting competing commercial use for two years, after which the software converts to Apache 2.0 or MIT.⁵ The OSI’s definition, by contrast, requires that an open-source licence must not discriminate against fields of endeavour.⁶

For libraries and developers considered directly—setting hosting intermediaries aside for a moment—FSL may describe a healthier contract.

Libraries receive source access, the ability to inspect and adapt the software, protection against permanent proprietary capture and an eventual fully permissive licence. Developers retain a temporary commercial space in which to fund creation and maintenance rather than watching an intermediary immediately convert their work into a competing hosted service.

The point is not that FSL is the only answer or that every project should adopt it. It is that formal licence restrictions may sometimes restore an obligation that open-source culture once supplied through norms.

If an ecosystem no longer reliably practises reciprocity, perhaps reciprocity has to be designed into its legal and economic structure.

That claim will be controversial. The OSI classification is coherent on its own terms. But it does not settle the prior question raised here:

Which arrangement better protects the long-term freedom and sustainability of libraries and the people who create their software?

A licence can be formally less open while preserving a more reciprocal relationship between users and creators. Conversely, an OSI-approved permissive licence can coexist with operational enclosure, ecosystem concentration and a business model that starves upstream maintenance.

The label matters. The relationship matters more.

What we owe each other

Open code is necessary. It is no longer sufficient.

A durable open ecosystem requires legal freedom, technical reproducibility, operational portability, active institutional stewardship, economic reciprocity, provider plurality, a funded maintenance metabolism and a credible ability to leave.

Creators owe users maintainable and honest software.

Libraries owe creators more than gratitude and occasional feature funding. They owe attention to whether the economic arrangements they choose can sustain the people and organisations carrying the product forward.

Hosts owe the commons reinvestment, operational transparency and an honest account of which upstream costs their prices include—and which they leave for others to absorb.

Foundations owe contributors active stewardship rather than procedural neutrality.

Libraries also owe the ecosystem more than purchasing decisions made under the reassuring label of open source. They owe it scrutiny: asking how many grapes went into the wine, who is being paid to grow the next harvest, and whether the price of the bottle sustains the vineyard or only the route to market.

All of us owe each other the willingness to ask whether the arrangements we have built are genuinely sustainable for every participant—or merely convenient for those who control the recurring revenue.

A commons cannot survive on one-way obligations.

FOLIO Developer, “Install a new back-end module to reference environments” and “Build, test, and deployment infrastructure,” describing folio-snapshot reference environments and the project’s AWS-hosted build and test infrastructure. ↩
Open Library Foundation, “About Us,” including its stated mission and “safe haven” language. ↩ ↩²
Open Library Foundation membership pages, including published fees for institutions, sponsors, and projects. ↩ ↩²
WOLFcon 2025, Rosalyn Metz, “The Future of Open: Building Trustworthy Infrastructure in a Fragmented World,” 24 September 2025. ↩
Functional Source License and Fair Source licensing descriptions. ↩
Open Source Initiative, “The Open Source Definition,” especially clause 6, “No Discrimination Against Fields of Endeavor.” ↩