Academy Software Foundation Technical Advisory Council (TAC) Meeting - March 4, 2026

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meetings/aswf?view=list&projects=aswf

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - Diversity & Inclusion Working Group Representative, OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language Representative
Daniel Greenstein - OpenImageIO Representative
Diego Tavares Da Silva - OpenCue Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative
Karen Ruggles - Diversity & Inclusion Working Group Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Individual - No Account
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Alyssa Alexis - SIGGRAPH
Robin Rowe - CinePaint
Lee Kerley - Apple
Olga Avramenko - Sony Imageworks / D&I WG
Prajna Nayak - D&I WG
James Helman - MovieLabs / ZeroTrust WG
Jonathan Gerebr
Jonathan Swartz - NVIDIA / OpenVDB
Tony Micilotta - Autodesk
Sean Looper - Miris

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Agenda

General Updates
- Add WG Charters to TAC website #1266
- 2026 Security Reviews #1137
- ORI follow up on Incubation #1167
- TAC Industry Representative Election #1291
- Dev Days 2026 #1288
2026 TAC Priorities #1208

Notes

General Updates
- Add WG Charters to TAC website #1266
  - Please write and contribute your charters. Examples from D&I and CI WG. Still looking for USD WG. Want to merge single PR if possible.
- 2026 Security Reviews #1137
  - Carol: will volunteer projects if a project doesn’t volunteer.
  - JF: audit needs to look at CI process, release, signing
  - JF: please look at #tech-leads and #wg-security channels for current attacks on CI and remediations
- ORI follow up on Incubation #1167
- TAC Industry Representative Election #1291
  - John: as per charter, TAC has a rep from each premiere member, each TAC project (defined as graduated stage), and appoint up to 3 industry representatives. We’ve had JF for a number of years. Technically we need to review every year, we should have done this last December. Also want to flag that JF needs to say “yes”, we’ll do the vote separately. Any qestions?
  - Larry: do long term WG get a vote? John: yes. JF: CI WG doesn’t show up on ASWF web site as long term WG?
  - Carol: do we want another industry rep? JF already has a vote via long term WG, if anyone else wants to be a voting member as industry rep, let us know.
  - Larry: is this an up/down vote on individual people, or n-people run-off? Does the TAC get to vote if there are only 3 candidates? John: up to TAC to nominate, so we can decide how we want to do this.
  - Carol: want someone very involved in our industry, also already involved in ASWF, involved in projects in meaningful way. Also a commitment to the TAC and attending meetings.
- Dev Days 2026 #1288
  - Carol: Coming up soon! Olga: Prajna is the internal outreach coordinator. Please respond to her, she can pass info to Dev Days team. Make sure you have good first issues labeled, with clear goal. Emoji helps but optional.
  - Larry: some people have expressed strong suggestions that Dev Days / Good First Issues should be highly discouraged from using coding assistants. The whole point is for new people to learn something, not swoop in and grab easy issues with coding assistants.
  - Carol: hopefully everyone has seen discussions around AI submission policies, to be discussed in TSC meetings this week and next so we can have the discussion at TAC in 2 weeks (before DevDays happens). For Dev Days, don’t wait until last minute to look at your backlog and groom it, update Clotributor to make sure no obsolete issues. Also for member company TAC reps, time to gather momentum at your company. Think about how to outreach at your company, we have great success stories to share. Get people excited, people who haven’t had a chance to contribute before, doesn’t matter what level they are at. Dev Days isn’t just for junior engineers, it’s for everybody who wants to learn. Be on lookout for contacts from Prajna.
2026 TAC Priorities #1208
- Carol: we brought up priorities at beginning of the year. What should we focus on as the TAC. Some we were already working on, best practices guide, you can participate with a PR, or just reach out to us. Don’t want to spend that much time here.
- Larry: please look at matrix spreadsheet for your org / project. Also adding more rows and columns as appropriate. Maybe you have a new product if relevant.
- Carol: reach out to Larry or me if you have questions on that spreadsheet if you are new to TAC.
- Carol: something else which came up was the possibility of a Qt working group. Has been floating around in our projects and DCCs. We haven’t had much activity since then. But since this is a “do-ocracy”, until there’s real activity, we’ll need a charter / scope of work. Larry: can you remind us of the Qt issue? Carol: compatibility between versions, what everyone should be using / not using. Should we be looking at alternative solutions? Larry: most DCCs use Qt, so we have a limited choice.
- Gordon: LTS position changed, used to be that Qt versions used in DCCs had 3 year support after we ship, with those change we can’t even ship before they are out of LTS. So we’re building on top of versions not supported by Qt Company. Also other changes to licensing, moving some stuff outside scope of LGPL version, like installers, builder. Running on unsupported version means do we want to take matters into our own hands and support our own version? Or look at a third party supported version? VFX Platform is looking at that. Also is there something that makes sense in a web environment, outside of QML? All that “drama” of being on unsupported software may be a non issue, we haven’t run into major bugs so far.
- Carol: so we should put this on the agenda for a future meeting to prep for it, have reps from VFX Platform. If there are things ASWF can do to help Reference Platform, could be good.
- Carol: 2 issues I want to focus on are:
  - How can we create more purposeful/intentional engagement of first time contributors
  - Project maintainer succession planning
- Slido Poll
  - Karen: from D&I WG, have been connecting to Dev Days, first touch point for the org. There are ripe opportunities for university / academia connections. Recently Texas A&M became associate member. We could develop this idea for academia, student and facility involvement.
  - Carol: Karen and I have been trying to find how to take burden off project maintainers. It’s an area in Dev Days where we haven’t quite figured out “what happens next”, same for SLP. When we get first time contributions, people don’t know they can attend our meetings. To turn single contributors into repeat, we need to engage with them.
  - Carol: we would be happy to create presentation, we have “intro to ASWF” decks. Would love to see TAC member companies doing it at their companies. Don’t know if anyone at member company has done a presentation at ASWF. Rebecca: haven’t heard it on our side, would love to hear from others if you have. Carol: it’s been done at Netflix Animation, they did it in context of Dev Days.
  - Carol: what about company resourcing?
  - Carol: JF suggested a PR template for first time contributors. Carol: that sounds like a good idea.
  - Christopher Moore: We’re trying to get organized here at Skydance. There is definitely interest. We’re just onboarding on first devs to projects now. It’s a work in progress.
- Project Maintainer Succession Planning
  - Carol: not just getting more contributors, but also getting interested in long term commitment, responsibility of being a project maintainer. If Cary decides to go off on a beach… We have other senior developers on those projects, but we don’t necessarily have a plan in place. Should there be a plan, should there be training. Is it part of ASWF mandate. Would like to have more ideas of what folks want to do.
  - Christopher Moore: similar to issues at companies. How to groom people. Also different from developer to project lead, maybe more diplomacy. Can be a stretch depending on the person. Carol: rarely happens accidentally. Unlikely that someone will “fall into your lap”, we have to be purposeful. We have to take our time that is already stretched, need judgement as to who would be a good fit. Getting more than 1-2 people who know how to release software. Larry: yes, designating a “release Manager”. Larry: John, any guidance from other projects / foundations. John: no community does this perfectly. Starting to look down the road, identify people in your communities, work with them slowly over time to get them involved, as opposed to a “big bang” transition? Someone who is a regular contributor, offer to become a maintainer. Not a ton of commitment. Also try to get folks from different organizations as much as possible. Try to channel energy. What other companies are using these projects, how can they get involved, look outside of companies currently involved. But there’s no one perfect way to do this.
  - Carol: give people tickets to do, but thinking ahead around project health. This group knows what it takes to be a project lead. Give someone small tasks, see how they handle it. Larry: we face same problems in our companies. There’s usually not a lot of succession planning below corporate level. When the leader of a group has to leave, there’s a moment of panic, then there’s a consensus on who should take over. What is scaring us is that we don’t even have a name. Who would replace Larry? Perhaps that’s the case, rather than thinking there’s no one else who can do it. We have a lot of competent people around, but individuals rarely step up.
  - John: when you have a unique individual who does a lot of stuff, these people can be hard to replace. So better to think not about “how to replace this person”, rather “how to fill these roles”, could be a couple of different people. I’m working on replacing an exec director who was great at a ton of things, we have to realize we can’t have that person again. So what’s unique about someone’s skills, and what could be handled by different people. And for people who are unique, mentor others on these skills.
  - TAC: maybe we could use annual review process, could be part of the template, “in the past year, we’ve had more than one person perform a release”. Some minimal distribution of maintainer responsibilities so the knowledge isn’t just in 1 person’s head. We expect projects to mitigate the risk.
  - Carol: apart from concrete knowledge, but of the people on the TSC, what are the core knowledge holders, and what are you doing to help and elevate them. I don’t think OCIO can replace Doug Walker, he and Autodesk wrote a lot of the current OCIO code base, so that intimate knowledge of where everything else is hard to replicate.
  - John: and you may not be able to replicate someone 100%. Also some of those leaders can burn out from carrying too much load. Can others carry some of that load. Carol: people do step up, in VFX, “we have to make it work”. But how can we be more prepared.
  - Larry: important to remember that deep knowledge about “where the bodies are buried” can be in someone’s head. But someone has to be in charge of figuring it out. If you are the maintainer, you learn the landscape fast. But you don’t learn that until you are in charge. Most projects only have one person with the deep knowledge in their head. Hard to split between multiple people. But it’s worth remembering that 7 years ago, you could have said the same thing about Jeremy Selan.
  - Carol: will add “project health” in annual review template.
  - Stephen M: I recommend making a policy of “performing a release is a two-person screen-share process”. It makes releases take extra coordination, but an occasional screenshare or screen recording of a release process (or other related process) can be invaluable for the team.
  - Larry: some projects have a RELEASING.md but it’s hard to tell if it has all the info or not.
  - Carol: keep thinking about these things, we will take this feedback, work on what can be generalized, TAC repo best practices, annual review template. We’ll see what happens with OCIO review in 2 weeks.
- Carol: looking on whether these “meta” discussions are helpful. Most TAC meetings are filled with annual review, but also want to have these kinds of discussion, hopefully they are helpful to projects. Anything you think would be a good topic please suggest. Next meeting we’ll be covering the AI code contribution policy, please come prepared for that, we want to put something in place.
- Gordon: is there a draft on AI policy? Larry: not yet, we want it to be advisory, rather than compulsory. We want projects to have something to start with. Lots of TSC discussions coming up. Projects who haven’t had those discussions, please make sure to have them before next TAC meeting.
- John: We have a base policy that projects should build from: LF policy
- Gordon: we need “lines in the sand” policies, and then policies than can be adapted per project.
- Carol: we also want to hear from member companies. Larry started a thread in #wg-ml channel. Larry: as a member company, don’t want policies that would prevent you from using projects as before. So any red lines, we want to know about it. Gordon: should we do a survey, “anything that would stop you contributing / stop you consuming?”. Carol: I’ll check with LF folks, could be as simple as an email. We do want to discuss this 2 weeks from now. Gordon: we may get a more diverse set of inputs, would be great to hear from people who contribute less.

Next Meeting Agenda

General Updates
- AGENDA TOPIC: AI code assistant policy #1195
Annual Review: OpenColorIO #474