OLF sustainability

K-Int

K-Int is deeply committed to FOLIO and to the Open Library Foundation. We have invested in FOLIO from its earliest years because we believe libraries should be able to build, operate and improve their essential systems in an open community.

But commitment does not make an economic model sustainable.

In K-Int’s assessment, the model we have used so far has left us approximately £5 million in the red. That figure is composed largely of salaries paid while we sustained teams and products between bursts of feature funding, together with work delivered at subsidised rates on the expectation that a sustainable, scalable business was just around the corner.

That approach has run its course. It would be neither honest nor responsible to keep pretending that the next feature project will somehow pay for all the maintenance that came before it and all the maintenance that must follow.

We have asked the community and the OLF board for help in finding a workable answer to this sustainability question. We have not received a constructive response that gives us a practical way forward. Waiting is not a strategy, so we are taking the initiative and putting forward a positive, proactive model for discussion: the K-Int FOLIO Sustainable Release Lifecycle.

Its purpose is simple: enable continuing investment in FOLIO modules, give independently funded work a temporary opportunity to recover its cost, and ensure that qualifying development has a clear path back into the open-source commons.

The ISV promise without an ISV business model

FOLIO’s promise was larger than creating one system around which hosting providers could build service businesses. Hosting is necessary and valuable, but it was meant to be one part of a broader ecosystem—not its only durable commercial model. FOLIO was also meant to be a platform on which independent software vendors could build focused, best-of-breed solutions for libraries.

That is the role K-Int is pursuing. Our purpose is specifically to explore the parts of the library systems landscape that are not well served by existing LSP and ILS implementations. We are interested in the edge cases, persistent pain points and important gaps that broad platforms can struggle to address well.

Libraries understand those gaps better than anyone. Owen will be reaching out directly to libraries and asking what they believe is missing, where current systems create friction and where focused product development could make the greatest difference. We want our roadmap to begin with those conversations and our software to close the gaps they reveal.

That is why the K-Int suite today concentrates on areas such as Open Access, resource sharing and inter-library lending, electronic resource management through Licenses and Agreements, and Serials Management. We invest in understanding these domains deeply and in producing the best answers we can for them on the FOLIO platform.

K-Int is currently unique among the companies developing FOLIO software in operating as a pure independent software vendor. Other developers are generally funded prospectively to deliver agreed features, or work for hosting providers investing to improve the service they offer. Both are valid and valuable ways to contribute. Our position is different: we invest our own money in a focused software product before there is necessarily a customer contract to pay for the work.

The missing piece is the platform-level sustainability model that FOLIO always appeared to promise. The architecture created space for independent applications, but the corresponding mechanism through which an ISV could recover continuing product investment never materialised. There is no dependable route that funds the long stretches of maintenance, security, modernisation and product development between commissioned features. K-Int carried that gap in the expectation that the platform economy would mature; instead, it left us deeply in the red.

The lifecycle proposed here is one possible route back to sustainability. We are now looking directly to libraries, consortia, developers, funders and other community participants to help test, improve and support it. We cannot wait for hosting providers, whose commercial incentives are necessarily different, or for OLF leadership, which has not produced a workable answer to this problem.

We are, candidly, making some of this up as we go. We would prefer to develop a transparent proposal in public, invite challenge and learn from its use than allow the absence of community-level leadership to end K-Int’s investment by default.

The sustainability problem

Visible features attract funding. A new workflow, screen or integration can be demonstrated, named and associated with a sponsor. Essential maintenance is much harder to see when it succeeds.

Yet a maintained software product also needs:

• framework and Java/JDK upgrades;
• current dependencies and security remediation;
• CI/CD and release engineering;
• data migration and compatibility work;
• architectural improvement;
• testing and regression work;
• documentation; and
• product-owner effort and coordination across FOLIO.

Customers and community participants understandably prefer to pay for visible outcomes while expecting patching, security, dependency currency and framework upgrades simply to happen. In an open-source ecosystem, however, someone still has to fund that work.

A major Grails upgrade can represent tens of equivalent developer-days while offering very little obvious new functionality to an end user. Without it, the module will eventually become insecure, incompatible or unmaintainable. Treating that work as valueless overhead does not remove its cost; it merely transfers the cost to whichever maintainer is still willing and able to carry it.

Our proposed lifecycle therefore treats maintenance and platform currency as genuine product investment. Features matter, but so do the foundations that keep those features usable.

A clear Apache boundary

The starting point is unambiguous:

Code released through the OLF FOLIO repositories is Apache-2.0.

K-Int starts from an Apache-licensed OLF release of a module such as mod-agreements. Nothing already released under Apache License 2.0 is withdrawn, closed or taken away. Existing Apache rights remain intact, and copyright remains with each work’s creators.

K-Int may create a downstream development line from that open baseline and invest further engineering in it. The lifecycle concerns how that new K-Int-funded development is released. It does not depend on arguments about historic ownership, and it does not restrict anyone else’s freedom to use or develop independently from the Apache baseline.

This boundary is both a licensing principle and a practical design constraint. It gives every participant a known open starting point and makes clear where K-Int begins carrying new development risk.

The K-Int Sustainable Release Lifecycle

The whole model can be expressed in one line:

(1) Apache-2.0 baseline → (2) K-Int development → (3) FSL release ⇒ (1) Apache-2.0

The double arrow at the end represents two parallel routes back to Apache: a time-gated release under K-Int’s policy, or an earlier release supported by funding.

At stage one, an OLF release provides the Apache-2.0 baseline. At stage two, K-Int undertakes new work, sometimes because a customer has commissioned it and sometimes because the product simply needs it. At stage three, where K-Int has carried the cost and commercial risk, it may make its downstream distribution available under the standard FSL-1.1-ALv2.

That distinction matters. Under the FSL terms, libraries can take the release and run it for their own operations; developers can inspect, use, modify and build on the source for permitted purposes; and the work remains available for research, education and services supplied to a compliant licensee. The model does not place a charge or artificial gate in front of a library’s ordinary use of the software.

The temporary restriction is on Competing Use. In practical terms, the freedom being narrowed is not the community’s freedom to benefit from the work. It is the freedom of a commercial provider to take engineering funded at K-Int’s risk and turn it into the same or a substantially similar hosted offering during the sustainability window, without reaching an agreement or contributing to the investment that will return that work to the commons. That is the specific economic gap the FSL window is intended to address.

From there, the development returns to Apache-2.0. The return can happen through either of the two paths shown on the wheel:

1. Time-gated Apache release. K-Int’s policy is to release qualifying development under Apache-2.0 after no more than one year.
2. Accelerated Apache release. An organisation, a group of organisations or a community initiative can fund an earlier Apache-2.0 release of the corresponding development.

FSL is therefore not the destination. It is an intermediate sustainability window within a cycle designed to produce more open-source software over time.

Why FSL

When K-Int undertakes development at its own cost and risk, the standard FSL-1.1-ALv2 provides a temporary commercialisation window. The source remains available under the FSL terms, while K-Int has an opportunity to recover some of its investment in developing, maintaining and releasing the software.

This is a sustainability mechanism, not an attempt to make FOLIO proprietary. The Apache baseline remains open, independent development remains possible, and the new K-Int work has a defined route to Apache-2.0.

K-Int adds new value after the Apache boundary. That value returns to Apache automatically after time, or sooner if the community funds its release.

This is also why K-Int uses the standard, unmodified FSL licence. We are not creating a bespoke FSL or changing what FSL means.

A guaranteed route back to open source

There are two distinct commitments here, and it is important not to conflate them.

The standard FSL-1.1-ALv2 has its own Future License provision: it grants Apache-2.0 rights on the second anniversary of the date a version is made available. That two-year conversion belongs to the standard licence itself.

Separately, K-Int’s policy is to make qualifying development available under Apache-2.0 after no more than one year. This is an additional K-Int release commitment, carried out through a separate Apache release. It is not a modification of the FSL and does not change the FSL’s SPDX identity.

The result is a one-year K-Int policy route, with the standard FSL’s two-year Future License remaining as an independent backstop.

Accelerating the Apache boundary

The community does not have to wait for the time-gated route. An organisation can sponsor an earlier Apache release; several organisations can pool their funding; or a wider community initiative can coordinate the effort.

That funding does not purchase exclusive ownership. It sponsors early release of the relevant body of work under Apache-2.0 for everyone. The sponsor helps move the open boundary forward, and every library, vendor, developer and community project receives the same open-source result.

This is best understood as sponsorship of the commons. It gives organisations a way to direct money towards the open availability they value without turning the result into a private deliverable.

There is also a simpler path when work is funded from the outset. K-Int and a prospective sponsor can agree that newly commissioned development will be released directly under Apache-2.0, without an intermediate FSL window.

Where the community funds the development risk, the community can receive the result immediately under Apache. Where K-Int carries the development risk, K-Int receives a temporary sustainability window before the work returns to Apache.

FSL is not the objective in itself. Sustainable development is the objective.

Why AUDIT.md matters

For qualifying work, K-Int maintains an AUDIT.md alongside the source. It is a transparent record of conventional equivalent professional delivery value.

That value may include analysis, architecture and design, implementation, testing, migration, compatibility work, security remediation, documentation, release engineering, product-owner effort and material FOLIO coordination. It makes the whole engineering investment visible, not only the feature that happens to appear in a demonstration.

AUDIT.md is not an employee timesheet. Actual elapsed implementation time and automation runtime are not the measure. Experience, good tools and automation may allow K-Int to deliver a result much faster than a conventional implementation. That efficiency should benefit delivery, but it should not automatically erase the professional and economic value of the result.

The audit provides a reviewable basis for understanding the development between two points in history and for discussing an indicative accelerated-release value. It also helps the community see how visible functionality and essential maintenance have supported one another.

Moving a coherent body of engineering

An accelerated Apache release moves the boundary through an audited tranche of development. It does not treat each attractive feature commit as an isolated item that can always be lifted out of the history around it.

Open-release acceleration funds the coherent body of engineering investment represented between two points in the development history.

That coherence is necessary because software changes have prerequisites. A feature may rely on a framework upgrade, a database migration, CI changes, security remediation or regression work that came before it. Releasing the feature while assigning no value to those foundations would reproduce the exact sustainability problem the model is intended to solve: visible work would receive funding while the maintenance that makes it possible remained unfunded.

This is not a punitive rule and it is not a claim that every commit has equal value. It is a way to preserve a technically sound release boundary and allow feature investment to support the foundational work on which it depends. The audit makes that boundary open to inspection and discussion.

We are also defining a Release Frontier application to make this easier to understand. The work is intended to show, for each module, where the current Apache community release ends, what coherent development lies beyond it, when it becomes eligible under time-based routes, and how pooled funding could accelerate the frontier. This tooling is still being developed; it will support transparency, not replace the review and release process.

Community choice, without lock-in

Nobody is forced to fund K-Int, and nobody loses access to the existing Apache software. An organisation can always choose to:

• use the existing Apache-2.0 OLF release;
• use the K-Int FSL release, subject to its licence terms;
• wait for K-Int’s Apache-2.0 release;
• sponsor an accelerated Apache-2.0 release, alone or with others;
• fund development prospectively for direct Apache-2.0 release; or
• implement the functionality independently from the Apache baseline.

That absence of lock-in is an important property of the model. K-Int’s development line is an offer to invest and sustain, not a claim over the community’s starting point or its freedom to take another route.

Our downstream repositories currently say, “We are not accepting PRs at this time.” That is intentional for the present model. Requirements, feature requests and technical feedback can—and should—come from libraries, OLF, EBSCO, GBV, Index Data and other participants across the community. Where K-Int undertakes the implementation, however, that work remains part of K-Int’s maintained development line. We do not need to introduce a complex inbound-contribution regime in order to listen, collaborate and respond.

What success looks like

Open source needs more than good intentions. It needs a dependable way to fund security work, platform currency, testing, migrations, release engineering and stewardship as well as the features people can see.

The Sustainable Release Lifecycle is K-Int’s proposal for balancing those needs. It preserves a clear Apache boundary, recognises the real value of ongoing engineering, provides a temporary window for independently funded investment, and gives both time and community sponsorship a route for moving that value into Apache-2.0.

We are putting this model forward because we want to continue investing in FOLIO—and because continuing under an economically exhausted model would serve neither K-Int nor the community.

K-Int adds new value after the Apache boundary. That value returns to Apache automatically after time, or earlier when someone funds its return. Either way, the long-term result is more open-source functionality available to everyone.

That is the outcome we want: a sustainable cycle in which professional engineering can be funded without permanently removing anything from the open-source commons.