Kimball Thurston - Chairperson, Weta Digital Limited
Bill Roberts, Adobe
Gordon Bradley, Autodesk
Roy C Anthony, DNEG
Matthew Low, DreamWorks Animation
Christina Tempelaar-Lietz, Epic Games, Inc.
Brian Cipriano, Google & OpenCue Representative
Sean C McDuffee, Intel Corporation
Larry Gritz, Sony Pictures Imageworks
Jean-Francois Panisset, VES Technology Committee
Cory Omand, The Walt Disney Studios
Daniel Heckenberg - Animal Logic Pty Ltd / Industry Representative
Eric Enderton, NVIDIA & Asset Repo Representative
Sean Looper, Amazon Web Services
Michael Min, Netflix
Michael B. Johnson, Apple
Greg Denton, Microsoft
Sean O’Connell, Advanced Micro Devices
Mark Visser, Unity Technologies
Ken Museth, OpenVDB Representative
Carol Payne, OpenColorIO Representative
Cary Phillips, OpenEXR Representative
Joshua Minor, OpenTimelineIO Representative
Chris Kulla, Open Shading Language Representative
Jonathan Stone, MaterialX Representative
Other Attendees
David Morin, ASWF
John Mertic, LF
Emily Olin, LF
Michelle Martineau, LF
Bill Ballew, DreamWorks Animation
Sean Wallitsch, AWS
Doug Walker, OCIO / Autodesk
Allen Rose, Madison Square Garden
Scott Wilson, Rust WG
Andrew Grimberg, LF Release Engineering
Nick Porcino, Pixar Animation Studios
Erik Straus, Netflix / Review & Approval WG
Lee Kerley, Sony Imageworks
Morgan Prygrocki, Adobe
Mathieu Mazerolle, Foundry / OpenAssetIO
Tom Cowland, Foundry / OpenAssetIO
Matt Davies, DreamWorks
Isaac Snow
TJ Jackson, DreamWorks Animation
Luis Villanueva, DreamWorks Animation
Alex Meddick, Rising Sun Pictures
Alok Hota, Intel
Jim Helman, MovieLabs
Michael Zink, WarnerMedia
Deke Kincaid, Digital Domain
Apologies
Cary Phillips, OpenEXR
Eric Enderton, NVIDIA / DPEL
Christina Tempelaar-Lietz, Epic Games
Agenda
Quick governing board update (Kimball)
Switching their meeting schedule around, will have a meeting at SIGGRAPH
Usage of Slack has gone up, which pushes us up to next payment tier, so that may be brought up.
David: ASWF is running at $1M/yr revenue, and our expenses have shot past our revenue in last few months. We do have a small surplus, but we need to “live within our means”, not let ongoing expenses to go past our membership revenue. Andrew Pearce (treasurer) has gone into details, one of the growing budget points is Slack, it’s growing and it’s good, but there are alternatives such as Discord. Are there ways to run this differently? Around $14-$15 going up fast (yearly). John: latest annual is around $20K annually, Slack is priced on a active user basis, want to be clear that it’s not a directive to get off Slack, but it’s a growing spend area, there are a lot of other things we would want to invest funding on. So is Slack is where we want to direct a lot of that investment in. Other LF communities have had the same discussion around Slack, some have decided to stick with Slack, others have decided to direct funding elsewhere (for instance Discord). But no immediate need to make a move.
Larry: want to push back on idea that there’s a “growing number of engineers”, the traffic seems pretty reasonable, the growth seems to be in general discussion outside of any project. Maybe that could be separated out in something else that’s free, while keeping actual project traffic on Slack? Kimball: yes, we need to think about this.
Carol: would be good for TAC to get a budget overview, give the TAC the transparency of where money is going, would be helpful and give context. For instance what does $20K mean out of context? Have to look at it in relation to other spend.
Kimball: reason why this is coming up is that yearly renewal is coming up.
Sean Wallitsch: we gained a bunch of Slack members after Open Source Days, so if we want to move to other platform, we might want to do this before next Open Source Days.
Joshua (chat): For context, it would be great to see a pie chart of how all our other expenses relate to this one are
Larry (chat): Re Slack: it would be interesting to know the number of subscribers, messages, or unique posters per month (or whatever stats are most relevant to how we are charged) broken down per channel
Carol (chat): the D&I programs are likely a large contributor. OCIO currently doesn’t use ASWF’s Slack instance, we were considering merging… there is no rush to that, but that would likely be an add of several hundred folks in a short amount of time.
Thanks to efforts of many, SIGs can now be recorded, we are back to doing Open Source Days in person, Monday and Tuesday.
Keeping virtual presentations to a minimum, so won’t be widely pushing, but will be available for folks who need it.
Day 1 is bigger talks, hopefully get people to stay for the whole day.
Day 2 is more interactive, informal / BoF style, expectation that people go in and out. Also Board and TAC meetings.
Proposed agenda, up for changes based on availability.
We have 40 minutes slotted for most projects / talks, is that too much? Would you prefer 30? There’s not a lot of voices coming in from outside ASWF, industry talks, other projects. But most of the projects that used to be guests are now members. Don’t know yet who will present for USD.
David: draft agenda designed with Kimball, grouped projects in like minded categories. What are headliner topics that will bring in people to attend? Could start with USD update from a USD person, Board meeting gave thumbs up for general agenda. If we agree that we should have a USD update from the source, will reach out to Steve May at Pixar, asking Cory, looking for advice as to who would be a good person from Pixar to give a short keynote (30 minutes). Cory: will need to talk to folks to see if they have time given that they may already be planning stuff for SIGGRAPH. Also USD Working Group session, what would be the content? David: yes, good question. This is just a schedule, not prescribing what should be talked about. Could be shorter. USD WG has done collectively a lot of work / discussion, would be good to expose that to the larger community. Summary of the threads, 3-4 sub WGs, lots of material to report on. Cory: yes, will talk to the other members. David: will reach out to you offline to figure out how to reach out to about keynote.
Emily: tentative TAC meeting at end of second day, don’t remember if we did one before. Is there a desire from this group, is it too late in the day and need to take a look at another time?
Carol: schedule looks good, from OCIO perspective, we’ll take the time we can get, don’t want shorter. We’re not doing a BoF because of the costly registration, so it’s not worth it. So this is the opportunity to get an update out about work done, but would also like to have a bit of a discussion, sharing an advance of what we’re thinking about, maybe run a PollEV poll. Take opportunity to answer in this session, structure it somewhat differently than just a basic update. May release some updates slides in advance. We’ve been discussing this, and curious about what other groups are thinking they want to cover in their talks.
Kimball: speaking for OpenEXR, we won’t just be talking for 40 minutes, want to have a discussion about the future of the format, not just a presentation.
Emily: sounds like 40 minutes is the right time.
Emily: will be putting together speaker guidelines, and will have a presentation template to be used.
Will be hotel next to SIGGRAPH (Pan Pacific Hotel).
In theory you must be registered with SIGGRAPH to attend.
David: on the second day, we put the future of Linux for workstations (from Nick Cannon out of VES Technology Committee), second headliner that will relate to our community and other studios.
Side talks:
D&I panel accepted
Rust submitted a BoF
News Package:
OpenFX
OpenAssetIO (?)
DPEL assets
Project releases?
Action item: get back to Emily about any conflicts.
For the Working Groups, could be a combined presentation for Rust and CI, Rust has submitted a separate BoF.
Joshua: OTIO team may only have a single person at SIGGRAPH, if we pre-record what we want to show, is that OK, or will it feel awkward? Emily: you are not the only one, if we pre-record, would be safer than having you doing it virtually. It is important that for any virtual presentation, there is someone on site familiar with the material, just in case. But it will be OK to pre-record.
Larry (chat): I think we had previously talked about MaterialX and OSL sharing a single slot, as we did last time. Jonathan: 40 minutes sounds like a good minimum length of time to me, though we have 7-8 proposed talks for MAX, and could easily use a full hour if it were available (as with OSD 2021). Good point Larry, though we’re happy to include overlapping talks (eg MaterialX closures in OSL) in the OSL event if that’s better. Larry: Is one of the MAX talks by any chance about the OSL+MX collaboration on standard closures? If so, that’s by far the most important thing OSL has to talk about. Jonathan: Yes, that’s definitely one the planned talks, and we’d be happy to make that part of the OSL event if that makes more sense. Either way works for us, and it depends on what other material might be available for each event. Kimbal: That is why they are still next to each other - so you guys could do a joint meeting together if you so choose. Jonathan: Agreed, Kimbal, and I like the adjacency of those two events if we choose to make them separate collections of talks.
Finish OpenAssetIO review (vote?)
Tom / Mathieu are here. Any final questions? Should we have a vote?
Mathieu: thanks for comments on email thread, sparked up discussion, good to know that there’s interest in the project, and naming discussion is important. More importantly is interest in the problem that we’re trying to solve, want to make sure we are aligned with the interests of ASWF.
Carol: let’s do it! Motion for a vote, Jonathan seconds.
John: accepting at sandbox level? Carol: yes, that’s the motion.
Erik: have had great comments in the document since last meeting. There’s an additional section added by Gordon representing the plans of Autodesk of how to manage commercial RV alongside the open source version. We can’t be the ones supporting all the commercial RV users! Documents the clear separation of responsibilities, keeps the support piece out of scope for ASWF.
Erik: larger outstanding conversation is structural: we have 3 initial projects that want to come into the foundation, they all have their merits. We expect the 3 to ‘draft off’ each other, over time come closer to a single project. But initial goal is not to ‘slam together’ all 3 projects right away. Organizational piece is that in order for the vision to work, the 3 teams should have shared conversation about this strategy. There should be a community obligation to come together under a “umbrella” organization, binds the projects together to hopefully come to expected outcome of a collection of components that can come pre-assembled, or be assembled in different ways to make a full fledged review system.
The organization structure needs to be fleshed out: have some ideas of how to structure the umbrella organization, but haven’t worked out the details yet. Is this workable / does it make sense? Is a TSC the right place to do this?
JF: nothing says a project can’t have multiple deliverables?
Carol: I think the proposal is good, we want to be all aligned and settings folks up for success. Don’t have an issue with an overarching TSC over different projects, but these are individual projects that need governance as individual projects, what I’m hearing about RV or xStudio, they need to stand alone, they have their own goals. While I support the common vision, let’s take one step at a time, get these projects open sourced, work through the process of getting them into ASWF, then a fourth project could be the umbrella organization that works on bringing them together. For a certain amount of time, we’re going to need RV for instance, and that’s going to go into an individual project. People responsible for RV would have to wear two hats and also think about future integration with other projects?
John: some of the scope of this proposal is not only these 3 projects, but also outside ASWF projects? Erik: For the direct collaboration of having a future with a unified playback system, there’s value to the locality of projects, shared leadership. Makes sense to inherit from OCIO, but no desire to include their leadership, it’s a separate, standalone component that other projects already depend on. There are additional projects bubbling up outside ASWF that are contenders for use inside a system like this. OpenAssetIO would have an impact. Also OpenAnnotationIO, outside of ASWF, closely collaborating with WG, up to them if they want to become part of ASWF.
Sean Wallitsch: don’t see a world where the direct governance of these projects is run under ASWF, Autodesk isn’t going to run RV out of ASWF. The part we want to see under ASWF is the effort to merge the projects into a single deliverable. Doesn’t mean that entire project has to be run out of ASWF.
John: is the scope of the project more the coordination between these projects, and the projects remain single organization owned projects, or would the projects become individual projects, with a separate group that manages integration?
Erik: the intention from the companies would be that the repos would come under the foundation. There would still be influence from the companies, but the repos would be “neutral” under the foundation. Also clears up a lot of hurdles for these companies that are organizationally challenging to run these projects on their own, there’s a lot of value to have the code and infrastructure living under the ASWF.
Larry: the 3 companies did intend to make these projects community run, and see it as a feature that they are under shared governance. Don’t want the projects to come into competition and not work towards a shared future we are hoping for. 3 companies explicitly feel the shared governance is important. Gordon: similar scenario with OCIO, had some internal tech (SynColor), had overlap but was different, saw a lot of value to contribute our technology, but rebuild on a common infrastructure. Turned SynColor into a big piece of OCIO v2. Long term don’t want to maintain RV as a big, separate code base. There’s value on using a common player core instead. But there is a separate between the commercial product, license and support, not trying to push that to ASWF. But the core player, plugins, graph technology… At some point the proprietary layer will get thinner and thinner. We want to make sure there’s a sample player on top of the core of RV. Joint TSC would look at duplication of technology, pick the best and refactor. That’s what the TSC needs to figure out.
Sean: sounds like with 3 initial consumables, they would still need their own direction / governance, with overall goal of delivering a single consumable. Can we drive this from a single TSC? Larry: this evolves over time. But we wanted to feel as one team. Gordon: Autodesk is going to invest in this, there are 2 choices: can sit in uncorrelated group with its own roadmap, or under a shared umbrella, making it easier to eventually getting onto a common core faster. That’s what happened with SynColor, paused the internal development and put developers on the merge to make it happen quicker. Part of the contribution of this is the contribution of engineers. There are some studios with RV components that could be good to contribute. If it turns out to be 100% of developer effort is specific to individual project, that’s not progress.
Sean Loop: what’s the mechanism for making architectural decisions? Joshua: seems creating this TSC is the place to have those discussions. The projects already exist with their own directions, the ASWF can provide that place to find the commonality.
Kimball: may be a model to use to resolve future things. We had these discussions when Rez was coming in about how to integrate with other projects (spk).
John: this seems to align with a project in another foundation, 3 companies bringing in projects with some alignment, they created a similar TSC organization, with separate “squads” for each sub project. It worked well for them. (Zowe). That group tends to use their TSC as an architectural lead group. Some other projects do architecture work in a sub committee.
Michael Min: sounds like these projects are aware of the others, and already developing around the others. Are we over complicating things, and should we wait until we see actually coordination issues to create a common organization? Also there was a comment previously about how this might be a bit more “expensive”
Erik: CI/CD costs might be higher for running into separate projects? The value of the coordination is that the projects aren’t collaborating with each other right now, so we want to give them a forum, where can the alignments be found, look for community contributions for missing pieces. Having the projects coordinating independently feels like a longer path than putting everybody “in the same room together”. Don’t want to rely only on goodwill and timing, as opposed to active management of the outcome. Gordon: don’t want to short circuit the process, but will note that there’s a window of opportunity to announce this at SIGGRAPH, Kimball, is there a path we can look at? Kimball: we can vote now, or vote via email, we’ve done that before.
Carol: appreciate the discussion, similar to John. Would be good to have to have potential TSC members to raise their hand and document what is going to be done. Knowing there are dedicated resources for every project and with the overarching organization. David: agree with Carol, there’s lots of energy in the TAC, there’s the issue of how many projects being added, if we add 3 projects, where would new engineers come from, effort of open sourcing proprietary code. Someone mentioned cost, we need more members / other sources of revenue. Will this project bring new member companies, would be great to provide more resources. Are there other ways this could fund this, right now we don’t have the funds to hire specific engineers… This is a great project, and this is something the market needs. We might be able to create a membership drive around this. Feels like there’s another cycle of discussions we need to have about the next steps.
Kimball: Erik, can you incorporate feedback into proposal, tag some names. Erik: yes, will circle back with team offline, block out short term milestones, some filtering of the project needs to happen before they can be committed to open source repos. Like the idea of using this to draw new members to the organization. First example of an end-user accessible project, as opposed to libraries, so a lot of value to moving to that level, could have a much broader community. And we want to aim for SIGGRAPH.
Kimball: we can do vote over email so we can get wheels turning. Worth doing the legwork, likely to be one of the larger projects we undertake.
David: having a timeline of steps would be useful.
Chat parallel discussion: John: That makes a bit more sense. I do think there would need to be a separation of RV roadmap as a project vs RV as an Autodesk (or other company) product. So to be clear, all three projects would be a joint deliverable? And one consumable for end-users? Larry: Initially separate consumables, in some sense. Not unlike how OpenEXR and Imath are actually separate consumables, under one TSC. Kimball: But the end goal is to have one story to tell. John: Yep, that makes a bit more sense. Carol: though that is with the folks who know it best - are intimately familiar with that code. Same with OCIO’s two projects. John: this feels like https://www.zowe.org, another project I work with. 3 major components came from 3 different companies, overarching TSC. And then there are separate committer groups (they call them squads) for each component. And releases tend to be aligned for a single framework deliverable. David (chat): OCIO had (still has) an architect. Who would be the architect (or team of architects) for this project? John: At first, everyone will stick in their corners. Deke: except there is a large overlap in scope between RV and DNeg/XStudio. John: but over time, cross mingling will happen and new parties will get involved in other pieces. Which maybe jumpstarts the collaboration. Larry: I think we do not want 3 new seats on the TAC for 3 separate projects each of which is thinking a “me, you, them” mindset. The sooner everybody thinks they are one team, the better. Michael: Larry, I don’t think we’re at that point? Again, seems like we’re thinking ahead of ourselves a bit. Erik: I can build and org framework and the teams can put names into it. Consider it done.