2025-08-27 FOLIO Futures Proposal

1 min

Scribe

@Shelley Doljack is next, followed by @Jeff Gerhard

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits.

5-15 min

FOLIO Futures Proposal

ALL

• Follow up discussion of the FOLIO Futures Proposal from 08/11 meeting

• CC analysis: https://folio-org.atlassian.net/wiki/spaces/CC/pages/1167261698

• Ingolf: what is the technical aspect of it? It's a big field of aspects.

• Wayne: Notion of technical governance is loose. As a TC, we should probably weigh in on that. Proposals mostly about funding sustainability.

• Jenn: thoughts similar to Waynes'. Mike Gorrell (MG) proposal of taking on maintenance and funding. Some ways we interact with maintenance is through OST, and TC taking on evaluating modules and licensing, this turns into technical maintenance. The generous policy of allowing more languages (e.g. Go and Grails) included the idea that the teams choosing those languages would take on the maintenance tasks. Having a generalized maintenance policy sort of conflicts with that. Loose governance = community team takes on governance and not the TC.

• Craig: This is not the first time we've had this dicussion. TC decided to embrace a polyglot thing and voiced these concerns and now we've come full circle. If responsibility cannot be shifted to another team, what do we do? Remove the module? That would leave customers in a bind.

• Christie: Is there a place for developing pipelines for multiple pathways? If we get to a FOLIO app marketplace, where there is a gold standard for an app to get wrapped into FOLIO, including maintenance, there could be labels that convey the level of support that would come with that module, customers would be able to understand more what comes with the module. Similar to the open access model.

• Maccabee: Some of MG's proposal is what Christie was talking about. More transpsarency about the level of support and maintenance for each module.

• Craig: need to be careful with how to proceed. We don’t want to incentivize oddball tech stacks because teams will get paid for maintenance on it.

• Ingolf: ongoing discussion regarding the ERM modules and the grails-update problem. The whole community should not be charged with the maintenance cost but the institutions that implement them should be aware what the maintenance costs are. These things should just be communicated to the community.

• Maccabee: TC's job to present the technical problems to the community councils and communicate what the issues are and will be. Case in point, the ERM modules grails update issue. Briefed CC about this but it would be helpful to have something written down about it and potential solutions.

• Jenn: Can we not discuss things because they're under the CC's charge? We can't do the work with OST and module evaluation when there's this cross-section of issues with other council charges.

• Maccabee: Talking about and elevating the issues is what TC should do. Identifiying problems versus of having the burden to solve them. CC is charged with the burden of solution and they're wrestling with this charge.

• Wayne: Interesting thing to talk about is the places where these proposal documents intersect with technical governance in ways we care about. Maybe we have mechanisms that are able to deal with custom development from a new team? We can evaluate new modules, evaluate if technolgies are officially supported, etc.; maybe the mechanmisms we have are fine and we should go through those proposal documents and see where our processes/mechanisms would break down. So mabye this discussion is premature.

• Christie: question about the process: I would like to better understand what the process is and where the decision-making lies. Is the CC asking the TC for feedback or are we just tyring to stay on top of this?

• Maccabee: Yes, the CC did ask the TC for feedback, which has led to the summaries we are discussing today. No decisions have been made, just the ideation part that we've been asked to provide feeedback for. Expanding support for other languages is a good example of a decision that was made (grails) and has an impact now on maintenance.

• Tod: Followup on Maccabee’s and Christie's points: when we look at the council repsonsibilities as things with really hard boundaries, we run into grey areas and they become nobody's responsibility. With a more expansive view, we are seeing overlap of stakeholders and we're trying to figure out how to work through those grey areas.  The issues we've been working through the last couple of years could be characterized that way.

• Jenn: tri-council meeting is tomorrow. What are the hot topics we've come up with? We will likely discuss these things tomorrow. I hope CC will form a group that inlucdes members of other councils. The micronaut thing that Kevin wrote up about and the security concerns (response from chat message).

• Craig: has anybody had conversations from K-int about micronaut and getting it on the OST?

• Jenn: we're looking for clarification on positioning.

• Wayne: we've probbably taken our dicussions on the proposals as far as we can. We probably need a philosophical dicussion at the tri-council level. FOLIO might need to be a monoculture in order to be sustainable. That's a legitimate position to take, but is that what the FOLIO project wants? If not, then we have technical and maintenance challenges to consider.

• Maccabee: Answer to Craig's question about K-int and micronaut: no, not until the community works out the governenace and sustainability aspect (reading from slack thread). For TC to talk about it doesn’t do any good if we don't document it for the other councils. CC needs to be able to talk about it at a practical level and not theoretical. A document would help with this.

• Jenn: What would the action item be for this?

• Maccabee: document the K-int situtation and the particular technical concerns. Document when we project the depenedencies and vulnerabilities become a problem, what current TC policies would lead to.

• Jenn: If we start a google doc and collect everything that's been identified so far and give that to TC, would that help? But I want the CC to understand the theoretical part. I don't want the TC to be viewed as bossy, we should really try to make community understand what we're trying to do and why. I will start the google doc and cut/paste things into it.

NA

Zoom Chat

09:09:40 From Craig McNally to Everyone:
What ever happened to the MOU initiative?

09:09:59 From Craig McNally to Everyone:
IIRC that included language about maintenance

09:11:29 From Christie Thomas (she/her) to Everyone:
That is probably where I got the idea, then.

09:25:06 From Christie Thomas (she/her) to Everyone:
Thank you for that. This helps me to understand the process.
Maccabee Levine:👍

09:25:48 From Wayne Schneider to Everyone:
Grails stack was original to FOLIO, it predated TC entirely IIRC
Maccabee Levine:👍

09:26:25 From Ingolf Kuss to Everyone:
sorry, I had lost connection . Now back again.

09:27:28 From Maccabee Levine to Everyone:
For example I included a CC member on the licensing subgroup...

09:29:23 From Craig McNally to Everyone:
Replying to "Grails stack was original to FOLIO, it predated TC...":
Note that K-int has indicated that they intend to adopt/migrate to using micronaut... I don't know if they plan to run that by the TC to get it on the OST

09:30:30 From Christie Thomas (she/her) to Everyone:
Replying to "Grails stack was original to FOLIO, it predated TC...":
What are the implications if a developer adopts a technology not on the OST or that is not approved by the TC?

09:34:08 From Craig McNally to Everyone:
Replying to "Grails stack was original to FOLIO, it predated TC...":
In theory, if it's in a new module, the TCR evaluation criteria would fail, and the TC would need to make an explicit decision on whether to accept the module anyway, or not.

09:34:56 From Wayne Schneider to Everyone:
Gradle

09:35:09 From Craig McNally to Everyone:
Replying to "Grails stack was original to FOLIO, it predated TC...":
if it's in an existing module, the situation is different... We are starting to trial doing evaluations of existing modules... It isn't clear what would happen if a module which has been around for along time fails a criteria like that during their eval

09:36:27 From Christie Thomas (she/her) to Everyone:
Replying to "Grails stack was original to FOLIO, it predated TC...":
Thank you.
Craig McNally:👍