2025-09-26 Tri-Council Meeting (at WOLFcon)

2025-09-26 Tri-Council Meeting (at WOLFcon)

 Date

September 26, 2025, 9 AM - noon CDT (Kansas City local time)

Location

 Participants

 

 Discussion topics

 

 

Item

Presenter

Notes

 

Item

Presenter

Notes

10 min

Welcome & Wifi hook up & Introductions (name, institution, role in FOLIO) & Agenda review

Note takers

 

 

30 min

“Hot takes”: Conference reflections

 

  1. What did you observe at the conference?

ML: interest in marketplace for affiliated software; strong positive reaction to LC presentation;

TO: plenary sessions resonated; tied int ongoing questions about sustainability and QA

CS: lots of ambitious proposals on the table - how can we focus on the MVP?

JE: governance - no handbook or documentation; relies heavily on Jesse K. How can we run this conference effectively so that people get the most out of it.

SP: What was the experience like for virtual attendees?

JF: video and audio was good; resolution was sometimes bad. There was always one person in the room paying attention to the experience online

OA: Several sessions with AV issues including a laptop dying. Opportunity for standardizing?

VF: Someone had to volunteer as moderator

CT: setup was not the same in each room

AM: maybe there should be someone moderating at each session - watching chat, passing mic, etc

MS: it was helpful when the moderator said how many people were in the room

TO: council members should not moderate

JE: virtual presence is significant

CT: not all presenters have the wherewithal to moderate - may

JE: this was the first year we had a speaker info session but not everyone knew about it

MS: it’s great that everything was recorded, it would be great if they were published quickly like last year. It was great that it was more diverse. more general interest and projects beyond FOLIO.

JE: would be helpful to post the schedule for each room, default to captioning; we are an international project in German or Polish

MS: English is lingua franca or international conference.

TC: would people be interested in Canada or Mexico for 27?

MS: what about Asia or Africa? how can we be more welcoming to other people on the project

TC: Koha has also been successful hosting regional meeting

JE: we need to think about cost

RK: Might be difficult for US institutions to travel in coming years

JC: length should be a consideration. Can we consider more 30 min sessions.

JC: we need to talk about how to count non-code contributions

TC: training could be a value-add for members

AF: excitement came from institutions learning about how other institutions are solving problems - need a centralized guide, place to share documentation

 

  1. What advances or updates were made during WOLFcon that influence any of the Council discussions?

 

  1. What new topics emerged that merit Council attention?

 

30 min

Core Problems & Positive Vision for the Future

 

  • Core Problems & 3 models

  • 4th model: brief representation

  • What are the smallest possible steps we can take?

  • What’s the next step?

SP: (On the 4th model) - Community Development Framework - Purpose is to synthesize the three models into a coherent proposal with the best ideas from all of them and provide a framework for moving forward. Touched on 4 common themes running through all of them: funding, governance, communication, and process. Core principles:

  • There are finite points that can be used to cover maintenance and development of FOLIO modules.

  • There will be tiered categorization for modules: Core, Community, and Participating. Points will (should?) cover Core and Community modules.

  • Allows for direct funding for development.

  • Support score and development score. Support points will be covered before development points.

  • Will require 1 FTE to manage the CDD.

JH: Concern that this will fall flat if there is no new revenue.

SN: There is a lot we can do with existing resources.

JC: keep in mind the problem we are trying to solve as we decide on the MVP pieces.

SD: Looks like an attempt to gamify development and maintenance. Concern about the overhead of maintaining the framework. Who will do this work?

JH: In order for this to be enacted as a whole, the councils will each take on additional set of responsibilities. There are pieces that could be enacted without adoption of the proposal as a whole. Councils can delegate work to groups who act on behalf of the council.

SP: All of top three problems that came out of the reflections document are addressed by this proposal.

Shared Reflections:

WS: What are the implications for vendors that are already doing work? What is covered by points and contracts and what is in kind contributions?

TO: Work to understand and document the real cost of maintaining software, whether contracted or in kind.

CS: To get from our place to the place where we have the oversight to manage many legal contracts is considerable. Likes the DIP process and an increase in visibility of maintenance and development work. Early on we can use existing tools like Jira to provide insight and allow us to improve processes and gain understanding right away.

AM: Process for retroactively incorporating existing modules?

SP: All existing modules will be wrapped into the points system.

HK: Has the community ever decided what is core? (Not yet.)

TC: What are the funds that are needed for the proposal?

JH: Proposal leaves it up to the community council to determine the funds needed and raising those funds. Good ideas for reducing costs on AWS and brining in funds from members are already on the table.

Current proposal has to cover support scores for core and community modules.

TT: Dev teams are already spending a lot of time each flower release on support. And the number of modules are growing, and those modules have pieces that support parallel functions. Concern about the true cost of the support piece. Recommends that there needs to be a hardening of the modules to remove code for duplicate functions and data clean-up to improve the ability to support these modules.

JC: Why do we want to take over core support and development when vendors are already providing that and let them keep working while focusing community development on areas that are neglected?

SP: Stability, predictability, and future support improvements.

JC: We cannot write everything from the ground up and we cannot re-write everything. If we want to focus on taking over core support and development, then we should focus on that. If we want to provide an outlet for development in areas that are neglected, then we need to focus on that.

JH: If the vendors who are supporting the core modules leave or stop supporting these modules, then FOLIO will fall over.

JC: This is yet another scope. If we want to fund FOLIO as well as EBSCO does, then we need to focus on a fundraising plan.

TO: Community needs to be able make decisions in a timely manner.

SD: Vendor work should not be invisible.

SS: Need to balance transparency with cost of transparency. Need to simple and pragmatic.

AM: Q: Is part of the purpose of the proposal is so that vendors can be compensated by the community for their work?

CS: We are not in a position to implement this plan this year. We need lawyers and contracting staff. There are parts of the plan that we can focus on this year. Would it be a valuable year if we would implement the tiered module plan?

ML: Need to divide this up into achievable bits.Proposal is a long term goal. Another segmentable component is the marketplace. Can we do this without significant cost? Could strengthen development models around individual institutional contributions.

JH: Proposal does recommend a phased roll-out.

TO: Could we surface the cost and separate that from compensation? Would that give a good window into how this would play out?

HK: Koha has a successful model. Can we take a look at it? It is lightweight and low-cost.

TC: 2 million is about 4 times what we are bringing in now. (About 500k). The true cost of this is more than 2 million. Need to be able to demonstrate where the money goes. We have about 50-60 members.

HK: About 20% of FOLIO users are members. How do we increase that number?

JC: Picking a couple of the visibility tools and working on that would be a great place to start. Working on a Factbook for FOLIO that counts all contributions would also be useful.

AM: How to get smaller libraries to be members? What is the benefit for smaller libraries to become members? How can we get them engaged? We should focus on folks who are already using FOLIO.

HK: Need to articulate the benefits of being a FOLIO member. Where does the member money go?

AF: What has been the outreach to the community?

(Organic and spotty. We can do more as a community. German networks are an excellent example of organized outreach.)

WS: CRP is about making visible to members what is being done with their $$. Also, what about the hours and hours of non-developer labor that goes into FOLIO?

TT: Would it make sense to bring in marketing expertise with community funds?

VF: Member benefits - need to address them so that institutions have value that allows them to advocate for the expense of membership.

JH: Valuable member benefit is being on the councils.

MS: What membership is worth is not really transparent.

HK: Need to spend some time reaching out to smaller libraries to understand what would be valuable for them and make membership attractive.


TC: Specific things we can do over next 12m? Incremental steps?

Caitlin: Lightweight version of DIP process. PC will discuss this afternoon. In line with dashboard work.

Harry: All work in Jira now, and has points. Could create a dashboard to use data that’s there. Turn that into understanding of expenses.

Wayne: Dev teams determine their own point definition, so tricky metric. Technical Council could do the counting to determine support burden for existing software. Mostly Jira work. Maintenance-only, not new development.

Shawn: Addendum – work with vendors, German institutions, etc. to come up with estimates for aggregated, estimated dollar costs.

Harry: Community used to keep a list of orphaned (non-maintained) elements of FOLIO. Get that up-to-date. Look at those, estimates based on those. Update the existing wiki page.

Caitlin will raise that at the PC meeting. Jen E.: PC has looked at it before.

Tom T. Modules not receiving updates at all as highest priority. Also those just not receiving new features.

Steve: Incentivize people to contribute resources. I.e. AWS funding, transfer that funding to do something tangible on priorities list. More contributions means more vote. Get some of priorities done. Demonstrate that money can help enhance the product.

Harry: Would modify that – before stopping AWS funding, determine implications, what relies on that.

Tom C: Revisit AWS later in agenda.

Christie: Creating buckets of core, community, participating. Apply proposal criteria to the existing modules, to understand how that works in practice. What falls in what buckets.

Harry: Small group of people investigate how Koha does what it does. Very different model, hard to argue with their success. May cover development costs, marketing, … Parallel.

Caitlin: If tiering is difficult to solve, would prefer determining whose decision that is so a group can move forward.

Jeremy: Agree with analysis of buckets. As defined in CDDF, the only one we could fill is core bucket. Community bucket is dependent on existence of CRPs.

Stephen: Core is technically determined. Other buckets are community determined about importance.

Tod: First drafts of tiers from several perspectives could be illuminating.

Caitlin: We’ve had several proposals of tiers with different implications. Synthesize with what Craig and Vince have been talking about. To what is MVP.

Tom C: Many efforts over the past years, different lists.

Wayne: This work can happen in conjunction with estimating maintenance burden.

Maccabee: Jenn’s prev tri-council group doing these buckets? Look to those results for guidance.

Jenn: Technical and funding lists do not necessarily line up.

Christie: Individual councils can take up whether it makes sense to propose an investigation of the buckets.

Caitlin: Can PC take that on?

Jeremy: Tri-council group currently on future of community-driven development. Might be natural for that convo to happen.

Caitlin: Will discuss with Jeremy after the meeting.

Tom C: Membership drive should be CC’s work.

Tom C: Jenn and Shawn, get counting things going?

Jenn: Will schedule a meeting. Get wiki page up with counts committers. Build on those numbers. Connect with membership folks on what would help make the case.

Lisa: Good idea to study Koha.

Jenn: Existing report on OSS governance. Will join with Lisa. Christie, Harry also.

Maccabee: Ask Mike G. if he wants to be involved in that group as well, since his developer marketplace may have overlap.

Tom C: Groups should aim to report back at next tri-council meeting, Dec/Jan timeframe.

30 min

Line item contribution (aka passthrough) & Membership campaign

 

  • Status on line item contribution proposal

Stephen: Had agreement in principle on this from EBSCO and Index Data. Created tiering structure for the fees, and oppo to opt out.

Harry: Not sure about EBSCO’s approval.

Tom C: After CC meeting where this was discussed, Tom and Paul discussed with Chrisopher on bringing into to fruition. Agreement in principle, not signed, subject to further discussions within EBSCO. Suggested to raise again in 3w, not yet done. So it’s time to raise again and figure out. Still positive indicators at EBSCO but needs work to finalize.

Stephen: Shared draft document. Also drafted a letter from the CC to be shared with these institutions. Emphasizing again that it’s optional, can opt-out.

Tom C: Mike G. is on board, assuming that EBSCO is also on board. MOL not approached yet.

Harry: If this moves forward, there’s a bit of a sale here. Have to convince someone to become a member. That piece should be worked out first, if we want to increase participation from 20-30%.

Stephen: This is not membership, no benefits or obligations. And fees are nominal. $500-$2k annually based on item count.

Harry: Any estimates made?

Tom T: Could this be classified as a different tier of membership? Like a half vote.

Caitlin: Agree that CC discussion on membership should precede this discussion.

Stephen: Other members were Simeon, Mike, Christopher, Boaz. Goal was an MVP effort, separate from membership.

Jeremy: If these pass-through fees are not related to membership, could be a drive towards membership.

  • Membership campaign

Tom C: Great topic for CC discussion this afternoon.

30 min

AWSed

 

Stephen: At last year’s WOLFcon Tri-Council meeting, a decision was made on a set of principles for AWS spending by the community. 1) community should pay for truly shared infra. 2) individual Dev teams should have envs funded by their funding agencies. 3) funding convos need time for appropriate planning. So to move away from funding environments, towards truly shared infrastructure, including testing (BugFest). Today, not sure how much progress has been made, AWS envs funded. Budget shows $479k AWS costs projected for this FY. Actuals last year (FY25) were ~ $350k, after we capped spending at $30k/month. Current AWS budget is $380K. What environments currently exist that do not meet these principles? And can we plan for transferring those costs as planned last year?

Shawn: Discused with Simeon and Mark V. Quickly ran afoul of those principles. Community doesn’t know yet. Has a snapshot shared in confidence with that small group. Also ties into the “what is core” conversation. Met four times, good convos but hard to agree definitionally. First, per Wayne’s proposal, have to get a handle on maintenance costs. Not just Jira points but meeting with institutions on actual costs. Became too big of a conversation, abandoned. Suggest Simeon may want to re-engage this, tie into Wayne’s proposal earlier.

Jenn: Part of what was discovered is that vendors are paying for a great deal of community infrastructure?

Shawn: Yes, a great deal. All a community, but some members have obligations to customers & marketplace, so can’t be that open. Need a way to get aggregate numbers that don’t betray those obligations.

Tom C. Jeremy and Stephen have suggested reducing the AWS bill through provisioning other institutions' resources?

Stephen: Agreed.

Peter: I worked through commitments we have. With AWS, the more you commit to spend, the more you can save. To this point, with no guidance to leaving AWS, we have 3 year commitments on AWS spend. Compute savings plans, last one purchased in October 2024, expires in October 2027. $94k remaining of that commitment. Roughly $300k said we’d spend through October 2027, goes down over time. So don’t expect savings right away, there is a runway if we ramp away from AWS.

Tom C.: Also issue of who would be providing these “cloud” (to us) environments, when it could be online? Would that work with existing DevOps / deployment practices?

Jeremy: This forces the idea that if we were to transition to community infra, we’d have to stagger it, more prudent anyway.

Tom C.: Working group to work through details? Harry volunteered Mark V. Peter volunteers, suggests Yogesh also. Stephen volunteering. Stanford may participate. Some German institutions may be interested. Wayne would participate as DevOps lead. Stephen will convene the FIRST meeting.

Wayne: Distributing the infrastructure adds complexity, which isn’t free. May think about it as limiting the rate of growth, rather than absolute dollars.

Martina: German institutions will definitely take part, need to converse.

xx min

 

 

xx min

….

 

 

...

 

 

 

15 min

Summarize Action Items

 

 

 Action items

 Decisions