Link Search Menu Expand Document

ASWF TAC Meeting - 15 June, 2022

Video Conference Link

Voting member attendance

  • 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
  • JT Nelson, Pasadena Open Source consortium / SoCal Blender group
  • Sean Wallitsch, AWS
  • Doug Walker, OCIO / Autodesk
  • Allen Rose, Madison Square Garden
  • Scott Wilson, Rust WG
  • Andrew Grimberg, LF Release Engineering
  • Deke Kincaid, Digital Domain
  • Nick Porcino, Pixar Animation Studios
  • Daniel Flehner Heen, Storm Studios
  • Erik Straus, Netflix / Review & Approval WG
  • Lee Kerley, Sony Imageworks
  • Morgan Prygrocki, Adobe
  • Robin Rowe, CinePaint
  • Mathieu Mazerolle, Foundry / OpenAssetIO
  • Tom Cowland, Foundry / OpenAssetIO

Apologies

  • Cary Phillips, OpenEXR Representative

Agenda

  • Emily / Open Source Days
    • Goals
      • Drive project growth by attracting new developers and engineers through project updates
      • Strengthen existing communities by providing a space to gather
      • Attract new projects and members by highlighting the Foundations’ continued growth and success
      • Continue momentum for OPen Source Days, establishing it as the event for the open source community
      • Support global diversity by providing virtual options for attendees
    • No recording for SIGGRAPH SiGs. There are some developments happening, but planning as if it’s not happening.
    • Option 1: if we can’t record or have virtual attendees in a SIG
      • Monday August 8
        • Open Source Forum from 2-5 PM
          • 2-3PM foundation update / overview
          • 3-4PM three presenters share 15 minute project updates
          • 4-5PM one presenter shares highlights from the other projects / WGs
      • Tuesday, August 16 - Wednesday August 17
        • Virtual Open Source Days
      • Projects can still submit for BoFs at SIGGRAPH
      • Looking into a hotel meeting room for small project meetings - who would use?
    • Option 2: if we can record or have virtual attendees in a SIG
      • Monday, August 8
        • Full day presentations
        • Beers of a Feather from 5:30-7PM
      • Tuesday, August 9
        • Smaller, interactive BoF style sessions
        • Informal
    • Tuesday, August 23: TPC Conference, Virtual - have we submitted?
    • SIGGRAPH events can be used to funnel people to events the next week
    • David: we will have resolution as to what SIGGRAPH allows us to do at a SIGGRAPH meeting happening tomorrow, we’re not the only ones not happy about this combination of factors. We will know afterwards what SIGGRAPH wants to do, so we can pick between the two options. Apologies for now having a clear picture yet. Each option has its benefits, in both cases, it’s about what updates can be done at SIGGRAPH, at the past we had 45 minute presentations, now we’ll have some of these, but there are other ways to do these updates, maybe group some projects together. We will confirm very soon.
  • Ken: OpenVDB has a problem which is becoming a blocker, desperately need better hardware for CI system, can’t reproduce bugs reported by members. The problem is memory. We’ve watered down the build matrix, compiling on a single thread, using ccache.
  • Ken / OpenVDB: about to create PyPI packages, need to create an account, should we create an account just for our project, or for ASWF
  • Ken: do we have a process for announcing new versions, have just released 9.1, normally would announce on Google Forums, but retiring those. Is there a process where ASWF can announce these?
    • Emily: have announced some on the blog. Will be working on a playbook around marketing and PR for the projects.
  • OpenAssetIO proposal / discussion with Mathieu & Tom
    • Link to proposal
    • Don’t have a formal, rehearsed presentation, send deck ahead of time.
    • Trust everyone has received the slide deck submitted for consideration for sandbox status project.
    • Mathieu: OpenAssetIO has been a project that has had a long journey at Foundry. Was founded in a lot of the research we were doing a long time ago around bridging asset management systems and DCCs. What does an asset centric world looks like, and if it was more native in applications. Have precedent in Katana asset management API. Big thing holding back the industry is having standardized system for talking about assets across multiple pipeline tools, different parts of the pipeline, physically / logically isolated parts of the pipeline.
    • Tom: built and end-to-end prototype, and enhanced the Katana API and showed it at NAB 9-10 years ago. It was a pure Python implementation. Realized needed to pick up this project again, and should do it in the open. Didn’t want to do this behind closed doors, so it’s being done on GitHub. Have had good engagement from early adopters, that has already helped correct some design issues. Keen to keep community centric development model. When heard about sandbox level adoption, felt it was a good way to get things going, leveraging the ASWF organization. Don’t want to hold any IP in this project, and want it to be community shepherded. Have been in contact with other ISVs, Blender Foundation, want good adoption on both asset management and DCC side. Want to be as open as possible.
    • Mathieu: talked to John Mertic about sandbox level, seems like a good fit. Project still in early phase. Any questions from the TAC?
    • John: the sandbox is designed for projects that are extremely early on. Maybe not a complete codebase, or scope not fully determined. But it’s important to have that work have a place where it can be nurtured to the point where it becomes a “well oiled” open source project. We use the same concept in other Foundations. If you don’t have a stage like that, the bar can be too high to join, and projects go elsewhere. The ASWF can give the project that space, lend it the collaboration infrastructure (Zoom, Slack…) Happens in view of the TAC which can be there as a resource, but also conscientious not to push too hard externally. Expectation is the project would be in sandbox 3-6 months, not more than a year. Time it takes to get the alignment together.
    • Sean Looper: is one year consistent with the timeline you have in mind? Mathieu: yes, seems consistent. A lot of the contributions so far have been done under the power of Tom’s team, seeing a lot of design discussions in WG, so potential to accelerate the roadmap. Key thing the project needs to get to the next phase is to have reference integrations. That’s when you can have a real insight of the timeline to move to a next phase, time to do initial integrations with in house pipelines, OTIO, connection to USD.
    • Joshua: happy to see example with OTIO, it seems to fit nicely with the media linker OTIO already has. Should be complementary effort. From OTIO’s perspective, happy to see this, addresses a problem OTIO has been asked about but which is outside the scope of OTIO project.
    • Sean Looper: you mentioned AR for USD, also Katana, any other applications in mind for reference implementation / integration? Mathieu: within Foundry there’s a lot of discussion of how to adopt this API, good separation between the project and the internal teams. Discussions with Autodesk teams, also the OpenPype system. Tom: there’s a bit of a chicken and egg situation. Have been focussing on our own applications, as well as OTIO / media linker. Have been talking to OpenPype, also discussions with MovieLabs around their ontology and 2030 vision. Started shared project with OpenPype and PipeClub to extend ontology to CG pipeline. Had a lot of input from larger studios through the WG, have been chatting with Blender Foundation. Still early days with commercial ISVs, been trying to reach out as much as we can, and happy to talk to anyone.
    • Gordon: do you have any studios on board yet / adopting the current API? Tom: a bit early on, currently converting the internal Python PoC into something ready for deployment, doing this in the open. Have had good input from AL, Pixar, DNeg. Blizzard made a good call to switching to batch centric operations, allowed switching to a different model before it was too late. Before end of year want to have reference integrations. Easier to communicate when you can show what the project can do. But a bit early for production adoption, it would be a bit risky.
    • Sean Looper: do we agree that it would be a criteria for transition from sandbox to incubation, how many studios have taken interest / involved in a project?
    • Carol: that can be part of it, since it involves formation of a TSC, with multiple members and companies.
    • Sean: we want to make sure that we have dates in place to make sure we don’t adopt projects that don’t have users in our base of companies we represent.
    • John: that’s a missing piece even in the adopted stage, we’ve identified that we need a healthy number of adopters, but not necessarily companies. Could be something the TAC may want to look at and adopt.
    • Sean: may be a natural consequence of the makeup of our voting members, not overwhelmed by vendors. But we may want to codify.
    • John: could be good to keep expectations set.
    • Erik: it’s a very high bar to display incumbent systems in studios. They are going to need incentives or improves existing systems while minimizing displacement.
    • Sean Looper: move to include at sandbox stage. Larry: do we want to give people time to reach out to people in their organization who understand this better? If this was successful, would it have impact on facilities, or would it be difficult? I don’t feel like I have that information. Sean: but isn’t this the point of sandbox? For instance our WG approach could be morphed into that a bit more.
    • Jonathan: don’t see any red flags, but could do more readings, in particular the GitHub. Kimball: can we do this in 2 weeks? Don’t want to leave things hanging for too long, and that’s the point of the sandbox.
    • Gordon: it’s a very interesting space, feels like there’s a lot of interesting stuff there.
    • Mathieu: one of the reasons we’re interested in bringing it to sandbox phase, looking for oversight and input from TAC members would be very valuable. Running WG on our own power, modeling it as close as possible to ASWF, but it quickly reaches a ceiling, duplicating infrastructure. We’re looking to bring the discussion to the next level without making grand statements about adoption, since it’s a chicken and egg problem. Hopefully no downside risk for the project.
    • Michael Min: sandbox can be a good place to even “find the value”, sounds like there’s enough validation amongst the community. Would be the place where it’s great to put the spotlight and have the conversations. We can give more time to read the doc, but the spirit of the sandbox is that there’s been work done, does it have the requirements to become a full project.
    • Kimball: instead of forming a WG, this is going a project, there will be code, there will be an API, so the sandbox seems like a good place. Let’s plan on having something formalized by the time we have the next meeting 2 weeks from now.
  • Review & Approval TSC proposal / RFC - Erik and group
    • TODO: add link to document
    • Expectations is to share draft memo, and give everyone a couple of weeks to digest. This is a bit different than what Foundarion has done previously.
    • Gordon from Autodesk, Larry from Imageworks and Roy from DNEG.
    • WG for Review & Approval was first in stealth mode, then became more public a few months ago. 3 separate companies want to share code with the community. There’s a consensus that all the code is valuable, serves different potential markets, if we’re going to solve the Review and Approval problem, it’s not just about a player, it’s also about timeline, assets, annotations. Different than other projects where we take an existing project and put structure around it.
    • Trying to propose umbrella group around a group of projects, build a strategic roadmap for each project and build communities around each one, and integrate holistically so we can solve the larger problem.
    • This is new for ASWF, we think there’s a larger outcome than individual projects / contributions. We want to encourage community participation and expansion. The conversation about OpenAssetIO is on our list.
    • Proposing an umbrella organization as a TSC with a shared communal roadmap that attacks the problem, starting with the three projects submitted by companies. Then add to umbrella to address things in a more product centric way based on community feedback. We may not have a good answer for a specific point, does a community want to pick that up? Some work around merging annotations is a separate open source project that is interested in joining the foundation.
    • Challenges are:
      • New strategy, not clear cut as to what output would be
      • More product focussed than what we’ve had in the past
      • Higher overhead costs, multiple projects under a single TSC (CI infrastructure…)
      • Sandbox style effort at this point, need to engage both product and program management. It’s going to take a lot of effort to coordinate efforts between several companies. Will require real resources, propose that ASWF may find a resource to have someone work part time on this from a program management point of view.
    • Contribution projects are:
      • XStudio from DNEG: 2 year old review player that has been under construction inside DNEG, was expected to get open source from the start. Has OTIO integration, today it’s a standalone player, doesn’t yet have features for sync / multi site / asset management
      • Autodesk offered to open source some or all of RV depending on what makes sense. A lot of effort into structuring the object into modular components, allows to use as a framework / pick and choose components.
      • Sony Imageworks itview, focus on collaboration components. Itview has been around for 15 years or so, synchronization and multi user experience is strong, multi-participant reviews.
    • Want to end up with both a building block of components, as well as a more turnkey solution for companies that don’t have the resources to build it themselves using those components.
    • Best analogy to proposal would be the way the Blender project is run today.
    • Larry: OpenEXR TSC has split OpenEXR from Imath and manages two code bases that are coupled but independent. Similarly OCIO separates core libraries from configs and ACES. In many ways OCIO has been an inspiration for how this could work. It’s not 100% new ground, but we take it a bit further.
    • Carol: we do run OCIO with a single TSC, but have WGs under OCIO TSC: UI, config, documentation, operated pretty independently, in separate repos.
    • Gordon: there’s a belief that there’s value from all 3 contributions, they all bring something. Agreement that having a common player is valuable to the industry, but will take time and effort to figure out how that works. If we support projects individually under ASWF, it makes things confusing. Gives clear structure and message to people engaging with the project.
    • We want to be able to move quickly, can we approve both the model and the project at the same time through the TAC.
    • Carol: are you planning on moving all 3 code bases, as separate repos, then merge them? Gordon: trying to extract common framework, keep projects going and adopt common core. Erik: we think these projects can have legs of their own, merging the projects could happen in the future where a nascent project with its own repo is a collection of components from these 3 projects and others that makes a “new thing”, but that’s not the initial goal. Sorting this out, defining community needs and goals will take some time. Strategy about what a future combined project would look like is something we want to address.
    • Larry: the 3 companies are doing this “dance” of getting NDAs in place to look at each other’s code… Easier to just open source all 3 projects and then do it in the open.
    • Carol: lots to think about!
    • Kimball: struggling to think of this TSC as a “permanent WG”, or transition Review and Approval WG to a TSC, it has “done it’s job”. Erik: WG doesn’t have its own repos, a governing body, a lot of the mechanisms that the TSCs have to do things. We need the next step to have the structure in place, the governance… Localized decisions will have to be made for individual projects.
    • Joshua: appealing to have a single TSC across all 3 projects instead of separate TSCs. Forum for cooperation, this is what makes ASWF work well. If TSC sets up a structured way to set up this cooperation, it’s a hard problem to solve, but it’s encouraging.
    • Larry: part of the reason for this structure, didn’t want to end up with multiple, competing projects, desire future alignment, feels like it sends the right message.
    • Carol: a concern is the way forward could be one of those applications, what happens to the rest of the “abandoned” projects. A TSC is responsible for that block of code, now we’re talking about 3 separate contributions. We might have to work out a new TSC governance model. Would hate to have a bunch of dead projects, the ASWF is all about keeping projects alive.
    • Kimball: the reason why you would pick one over the other would also by nature make it a superset, and would show a clear migration path.
    • Erik: the subtle shift for the TAC to consider is that this is actively promoting is a new model, a shift in the direction of how the Foundation thinks about things.
    • Gordon: working out as an industry how we navigate multiple projects is an interesting problem, does it become a thin wrapper around common framework, do we retire… Great discussions for that TSC.
  • Don’t forget to fill out maintainer survey and project / WG board updates.