The business layer is infrastructure for the mission

The last Foundry post was about the module developer loop.

That work matters because a developer building an ILL, ERM, Open Access, Serials, Licenses, or Agreements module should not have to understand the whole platform before they can make a small, useful change. The SDK profile work was about starting from a released, production-shaped runtime and substituting only the backend or frontend being edited.

This slice turns slightly.

Not because we have finished the developer loop and are now moving neatly to the next item on a tidy roadmap. The work is more organic than that. We are unpicking different pieces of the same difficult problem space as we find them: developer experience, adoption, hosting, institutional agency, operational support, product activation, and the business model needed to keep purpose-led open infrastructure alive.

This time the work touches ki-console.

ki-console is not simply “the storefront for Foundry”. It is a K-Int project exploring what a console-style application might look like for direct product activation and service management. What would it mean for a library, consortium, evaluator, partner, or customer to discover a K-Int service, request an instance, provision a workspace, evaluate it, understand what is running, export or back up their data, and move between trial, free, paid, hosted, self-hosted, or hybrid operating models without every step becoming bespoke consultancy?

This particular slice asks that question with Foundry in view.

From developer loop to adoption loop

A healthy open-source ecosystem needs more than code that can be built.

It needs code that can be tried.

That sounds obvious, but it is often where open library infrastructure becomes fragile. A module may be open source, technically sound, and useful, while still being difficult to evaluate. Someone has to provision it. Someone has to host it. Someone has to wire identity, routing, tenant state, reference data, backups, upgrades, monitoring, support, and the inevitable odd local requirement.

If the only practical path from interest to use is “start a bespoke project”, then adoption depends on consultancy. Consultancy is not bad. K-Int has lived for a long time through direct relationships, funded development, implementation projects, and long-term domain partnerships. Much good software has been written that way.

But a module that is easy to build and hard to try still has a broken adoption loop.

The Foundry Module SDK work tried to make the developer loop smaller. This ki-console slice starts exploring the adoption side of the same problem. How does a useful capability move from “this exists” to “I can try it”, “I can run it”, “I understand what I have”, and “I know what support or service relationship keeps it healthy”?

Not every useful library tool should have to become a six-month procurement conversation.

If the only sustainable route is a high-value institutional sale, then smaller tools, smaller libraries, smaller experiments, and smaller providers are structurally excluded. That is not good for open source, and it is not good for library choice.

The market problem underneath the technical one

For roughly twenty years, specialist organisations like K-Int have been able to sustain open-source library software through direct relationships: consultancy, implementation work, funded development, and deep domain partnerships.

That route still matters. It should not be dismissed. Some work is inherently relationship-heavy because it involves local policy, data, migration, training, governance, integration, and trust.

But the space around that model is changing.

The libraries sector has moved increasingly toward high-value, high-touch procurement patterns. At the same time, hosting-provider consolidation is changing the open-source side of the ecosystem in ways that resemble the consolidation that already damaged parts of the commercial library systems market.

The result is a squeeze that is easy to feel and harder to talk about carefully:

• the work is still needed;
• the expertise is still valuable;
• the software still needs long-term stewardship;
• libraries still need practical alternatives;
• but the direct consultancy route that historically paid for that stewardship is narrower than it used to be;
• and larger intermediaries can sometimes benefit from the commons without contributing proportionately to its upkeep.

That is not a complaint about a particular company. It is a structural problem.

Open source depends on stewardship. It depends on maintenance, documentation, testing, support, security work, upgrades, release discipline, design, and the unglamorous time spent keeping yesterday’s good idea usable next year. When the benefits of open work are captured without reciprocal reinvestment, the commons becomes fragile.

We cannot respond to that just by complaining about consolidation.

We need another route.

Purpose needs a vehicle

I have been thinking about this through the lens of the “purpose-led founder” idea David Schofield and Purpose in Action have been articulating: purpose is not an alternative to business discipline.

If the work matters, the business model matters because it is the means by which the work continues.

That is an uncomfortable sentence for many open-source people, but I think it is right. A purpose that cannot pay for maintenance, support, documentation, hosting, security, design, developer time, and operational attention is a purpose at risk.

Foundry is purpose-led work.

The purpose is to preserve institutional agency, local extensibility, and practical open-source capability in library technology. It is to make it possible for libraries to adopt useful vertical tools without surrendering every operational choice to a consolidated platform. It is to keep K-Int’s specialist work in ERM, ILL, Open Access, Serials, and adjacent areas available in a form that can be hosted, extended, inspected, and eventually self-hosted or hybrid-deployed.

But purpose alone does not run the service.

The business layer is not a compromise with the mission. It is infrastructure for the mission.

That is the role ki-console is beginning to explore. Not a checkout page stapled onto an open-source project, but a possible operational and commercial surface where adoption, evaluation, support, hosting, and stewardship can become explicit enough to sustain the work.

What a console changes

A console is not just an admin UI.

At least, it should not be if this work is to mean anything.

A console is a place where intent becomes operation. It is where someone says: I want this service, in this context, with this shape, under these terms, with this route to support or export or cancellation.

For K-Int products, that might eventually mean:

• discovering available products, services, modules, or offerings;
• requesting or provisioning an instance;
• creating a workspace;
• evaluating a service without a long procurement cycle;
• activating a free tier or trial;
• moving into a paid tier where appropriate;
• managing service instances;
• taking backup exports;
• understanding what is running;
• seeing what capabilities are enabled;
• connecting hosted, self-hosted, or hybrid operating models;
• lowering the threshold between interest and practical adoption.

The commercial aspect matters, but this is not only about “pay-for”. It is also about evaluation, free tiers, transparency, operational visibility, and customer autonomy.

If someone has to talk to us before they can try anything, the adoption loop is still too heavy.

If someone can provision something but cannot see what is running, export their data, understand the support model, or move from trial to service, the adoption loop is still incomplete.

ki-console is where we can start testing that shape.

What changed in this slice

The implementation is still early, but it is now concrete enough to be useful evidence.

In the local development stack, ki-console now has a seeded local Offering for a Foundry-backed ILL workspace: foundry-ill-workspace-local.

An authenticated Console user can open that Offering and see an activation form. The form is deliberately modest. It asks for a Service name and slug, an admin contact, tags, and a small ILL setup section. In this proof, those ILL fields are carried as product configuration intent. The Foundry bridge currently consumes the requested Service Capability, not the full ILL business configuration. That distinction matters. We have proved workspace creation and ILL capability activation, not a complete ILL policy-management product.

Under the UI, Console creates a Service and queues a provider-neutral provisioning command. The important contract field is desiredState.requestedCapabilities: Console asks for the ill Service Capability, while the local Foundry bridge maps that to Foundry’s operational ill capability activation.

That bridge is intentionally at the provider boundary. It is not Console secretly running Foundry scripts as its own internals. Console issues a durable command. A Foundry-side agent claims it, installs/verifies the operational catalog, creates the workspace, enables the requested capability, runs Foundry-owned reconciliation, and posts status readback.

The happy path now proves:

• Console activation creates a durable Service;
• provider key registration uses an approved local trust path;
• the provider bridge claims service.provision;
• Foundry enables ill@ill-2.1.3;
• reconciliation creates identity, tenant, platform-service, module, and route state;
• Console receives an active Service with an access URL;
• Foundry verifies the ILL route, MFE loading, authentication gate, module descriptor, and reference data.

There is also a negative proof. If the activation requests a deliberately missing capability, Console ends with failed_retryable, no access URL, and no provider telemetry report. That last point matters because telemetry should be success evidence for usage and billing, not a false signal emitted after a failed provisioning attempt.

This is still local evidence. It uses .localhost, local Zitadel instances, a local bridge, and developer smoke scripts. It is not a hosted-test product launch. But it is enough to make the adoption path discussable in code rather than only in diagrams.

From requested service to working workspace

The other side of the screenshot pair is Foundry itself.

The browser-led smoke signs into Console, opens the ILL Offering page, completes the onboarding form, runs the provider bridge, waits for the Console Service page to become active, and then verifies the resulting Foundry workspace.

The result is an ILL module running inside a Foundry Lattice workspace.

This is why the Console work is not separate from Foundry’s purpose.

Foundry asks: can we run specialist library applications in a sovereign app shell, outside the business model constraints that made it difficult to sustain them elsewhere?

ki-console asks: how does someone actually adopt that work, evaluate it, provision it, manage it, support it, pay for it where appropriate, and retain enough agency to trust it?

Those are different questions, but they need each other.

Openness needs reciprocal structures

There is a freeloader problem in open source. We should be honest about it without becoming bitter.

Open does not mean costless. It means the source, the rights, and the ability to inspect, run, modify, and participate are kept open. The work still has to be paid for somehow.

In library technology, this is especially delicate. Libraries need openness because institutional agency matters. Public, academic, and cultural-memory institutions should not be locked into opaque systems where they cannot understand or influence their operational future.

But specialist open work also needs reciprocal structures.

If open software is simply a commons from which larger intermediaries extract value, while the maintenance burden stays with small specialist teams, the model will not hold. The answer is not to close everything. The answer is to make the routes between use, evaluation, payment, support, contribution, and stewardship easier to see and easier to choose.

No unreciprocated extraction from the commons is a strong principle. It should not become a slogan that excuses bad behaviour from us either. It means we need practical mechanisms:

• easy evaluation for libraries;
• clear hosted service options;
• credible self-hosting paths;
• transparent service boundaries;
• ways to pay for support without buying a whole platform;
• ways for partners to participate without hiding the origin of the work;
• operational evidence that the software can be run, backed up, upgraded, and exported.

A console/control-plane model is one attempt to connect those pieces.

Lower the threshold

The hypothesis behind this slice is simple:

Open-source library software may need a lower-cost, higher-volume route alongside traditional consultancy and large procurement conversations.

That does not mean replacing relationships. It does not mean everything becomes self-service and unsupported. It does not mean serious implementation work disappears.

It means creating an entry point below the major procurement event threshold.

A library should be able to try a small useful thing. A consortium should be able to evaluate a capability before committing to a large programme. A partner should be able to understand what is running and how it is supported. A K-Int team should be able to put a maintained service in front of interested users without turning every enquiry into a bespoke project.

That is the adoption loop.

Discover. Try. Provision. Verify. Use. Export. Support. Pay where appropriate. Contribute where possible. Leave with dignity if the service is not right.

Those are operational verbs, not marketing ones.

Where this leaves us

This slice does not solve the business model.

It does not decide hosted-test pricing, institutional eligibility, public Context creation, backups, exports, cleanup policy, production telemetry, self-hosted activation, or partner commercial terms.

It does something smaller and more useful at this stage: it makes the next conversation concrete.

We can now point at a working local flow and ask better questions:

• What should a real hosted Foundry Offering look like?
• Which parts of ILL onboarding are product configuration and which are operational capability selection?
• How should a user move from evaluation to supported service?
• What should be exportable from day one?
• What telemetry is needed for billing without becoming surveillance?
• What failure states must be visible to the user and to operators?
• How do we support hosted, self-hosted, and hybrid routes without building another gatekeeper?

Foundry remains purpose-led work. It is about preserving practical open capability and institutional agency in library technology.

ki-console is part of learning how that purpose might become durable.

Not by pretending business is separate from the mission. Not by turning open infrastructure into a closed product trap. Not by complaining about market consolidation and hoping the old model returns.

By building another route.

The business layer is infrastructure for the mission.