In our proposal for a sustainable FOLIO release lifecycle, we argued that K-Int-funded development should have a clear route back to Apache-2.0: automatically after a defined period, or sooner when an organisation or group sponsors the earlier community release.
That describes the policy. It does not, by itself, make the opportunity understandable.
A library should not have to read Git hashes, compare branches or reverse-engineer a release file to discover that a maintained K-Int module includes substantial work beyond the current Apache line. A hosting provider should not be able to treat months of framework, security and release engineering as if nothing of value has happened simply because those foundations are less visible than a new screen.
We have therefore started building Release Frontier: a public, read-only view of the evidence that explains what K-Int has delivered, when it first appeared in an FSL source release, what the Apache baseline currently contains and what an earlier Apache publication would unlock.
Starting with Agreements
mod-agreements gives us a useful worked example because its real history includes all the awkward
cases a simplified release diagram tends to hide.
- FSL 7.4.0 first made the six-day Migrate legacy agreement settings feature available.
- FSL 7.4.1 corrected residual version metadata. It retains that feature but does not pretend the correction created another six days of value.
- FSL 8.0.0 introduces four further assessed engineering features and retains the earlier settings migration.
Release Frontier presents those as release facts and feature relationships, not points forced onto one misleading commit axis.
The live Agreements story separates immutable FSL releases, the features they contain and the cumulative Apache promotion frontier. Select the screenshot to open it full size.
The current Agreements projection contains 132.75 assessed effort-days across five named features. At our published nominal rate of £1,200 per assessed effort-day, that represents £159,300 of assessed delivery value beyond the Apache baseline:
| Delivery scope | Assessed effort | Nominal value |
|---|---|---|
| Migrate legacy agreement settings | 6 days | £7,200 |
| Grails 7 and JDK 21 major upgrade | 68.5 days | £82,200 |
| Grails 7.2 fleet-canary alignment | 28 days | £33,600 |
| Standard FSL release-model correction | 6.75 days | £8,100 |
| Reusable OCI publication foundation | 23.5 days | £28,200 |
The effort comes from the repository’s AUDIT.md. Release Frontier does not derive it from the
number of commits, elapsed development time or the amount somebody happens to contribute. It applies
an effective-dated valuation policy to that assessed effort, records which policy produced the
figure and leaves unknown effort as TBC rather than inventing a number.
Value is not a payment balance
These figures are deliberately prominent, but they need to be read correctly.
Assessed delivery value is not an invoice, a funding balance or a final sponsorship offer. It is a consistent way to show the scale of professional capacity represented by the work: analysis, architecture, implementation, testing, security, documentation, release engineering and ongoing stewardship.
That distinction lets us be honest before the commercial mechanism is complete. The software can show that Agreements contains £159,300 of assessed value beyond Apache without claiming that a funding round is open, that any amount has cleared, or that publication will happen automatically.
It also enforces the linear nature of the lifecycle. The £7,200 settings migration is the next exact candidate cut. The later FSL 8.0.0 cut is cumulative: it contains that prerequisite and the four later features, so its current assessed value is £159,300. A later feature cannot be cherry-picked past earlier source it depends on.
Making maintenance visible
The OCI publication work is a good example of why a feature name and commit subject are not enough. Much of its present relevance is about SBOM generation, provenance and software supply-chain evidence—concerns that became more visible after the original work was described.
Release Frontier therefore keeps the factual delivery evidence stable while allowing reviewed, versioned editorial annotations to explain why a feature matters now. The annotation can improve the public explanation without rewriting the assessed effort, commit boundary or release history.
The same value-led summary works at family level. This matters as the inventory expands from the first K-Int modules to pristine FOLIO modules and modules we patch for Foundry.
The FOLIO family view leads with named assessed value for K-Int-maintained lines while keeping a pristine external component visibly outside the FSL-to-Apache railway.
Commit divergence still appears as maintenance evidence. If the external FOLIO repository moves in an unexpected direction, Release Frontier flags the variance. But a raw count of commits is not allowed to masquerade as customer value.
A practical call to action
The economic point remains the one set out in our sustainability proposal. A hosting provider can repeatedly earn revenue from Apache-published work across its customer base. K-Int gets one practical opportunity to recover the investment that created and sustained that work before every provider can commercialise it.
Release Frontier is intended to make that imbalance discussable in concrete terms. Libraries can see the features and foundations available beyond their host’s Apache baseline. Providers can see the exact cumulative release they could help move forward. Sponsors can support an earlier Apache release for everyone rather than buying an exclusive branch.
The first view is intentionally read-only. Commercial participation, private FSL licensees and payment processing require their own authenticated records and disclosure controls. The public site starts with the more fundamental job: making the engineering contribution and the route back to the commons visible, traceable and hard to dismiss.
You can explore the worked example on the Release Frontier Agreements page.