ASWF TAC Meeting - 08 March, 2023

Video Conference Link

Voting member attendance

Premier member representatives

Project representatives

Carol Payne - OpenColorIO
Cary Phillips - OpenEXR
Jonathan Stone- MaterialX Representative
Joshua Minor - OpenTimelineIO
Ken Museth - OpenVDB

Industry representatives

Jean-Francois Panisset - Visual Effects Society

Other Attendees

David Morin, ASWF
John Mertic, LF
Yarille Kilborn, LF
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Scott Wilson, Rust WG
Stephen Mackenzie, NVIDIA/Rez
Doug Walker, Autodesk
Sergio Rojas, Different Dimensions
Daniel Heckenberg, Netflix
Jean-Christophe Morin
Robin Rowe, CinePaint
Andrew Pearce, ASWF Budget Committee
Spencer Stephens, MovieLabs
Mitch Prater, Laika
Kerby Geffrad, Autodesk

Apologies

Agenda

Rez Project Review
Budget Committee Report

Notes

Google Season of Docs (Carol Payne)
- No updates to share, OCIO still working on an application
- Jonathan: is Google SoD application already started? Got a request on MaterialX with someone who is interested in doing a PyPI implementation for MaterialX? Carol: that sounds like Summer of Code, separate from Season of Docs, application deadline for Summer of Code has passed, ASWF not participating. Jonathan: will look closer at which program they are part of. PyPI implementation would seem like a Summer of Code thing.
Summer Learning Program (Carol Payne)
- Blog post launched today
- Focus on underrepresented groups, LGBTIA+, accepting 20 learners.
- Post to share on a LinkedIn post
- SLP team led by Karen and Kaitlin has put an amazing confluence Wiki, all the SLP info is on Confluence Wiki, including volunteer opportunities (link in chat)
- Also the volunteer application form for anyone interested in volunteering, even if you were a volunteer last year. Will reach out to people who volunteered last year. Asking the TAC to share this information with your networks: university, company. There’s a call for volunteers template you can copy-n-paste for your company, will want to customize it a bit.
- Kimball: was fun to do last year, great program, recommend participating!
Rez Project Review (Stephen Mackenzie)
- Rez is pretty new in the ASWF, still lots of stuff we’re working out.
- Project Info:
  - Description: a lightweight cross-platform package manager written in Python
  - Build and release packages to a central repository, then consume them in standalone configured environments.
  - Lots of useful information in legacy Google Groups list, would like to get rid of it, but would like to capture this information somehow. John (chat): ping for me help on this, we’ve done this a lot before.
  - TSC was just formed in August
- History
  - V1 implementation at Dr.D Studios circa 2011
    - Author previously worked at MPC London
  - V2 implementation at Method Studios LA, circa 2014
    - Much more extensible - pluggable package repos
    - Animal Logic first external user
- Incubation Progress
  - DONE:
    - Technical Charter Approval
    - Legal
    - Governance
    - LICENSE
    - CODEOWNERS
    - README
    - License Scan (one small caveat)
    - Defined Architecture and Features
  - TODO:
    - Contributing
    - Code of Conduct
    - Release
    - Support
    - CII Badge
    - Defined Mission and Scope
    - Roadmap
    - …
- Historical Rez commits
  - Should see a lower number of commits next year, a few of TSC members have recently changed jobs with less Rez exposure
  - Allan has done a lot of the commits over history, showing historical commitment to project. But shows the dependency on Allan, high “bus factor”, we want to find ways to capture knowledge from Allan, make it more of a community project.
- MaterialX had a “organizations using” slide. Organizations using rez? At least 4 member companies are known to use Rez, and a lot of smaller companies as well, but no one is “officially” recognizing that they are using Rez. Need a users.md file to keep track. There’s a reason behind that, software management is not seen as a “cool” activity, there’s nothing visual to show. We do have a 2021-ish spreadsheet of companies where someone in the org was willing to submit information about Rez usage. But that spreadsheet doesn’t mean the company is OK to publicize that, or still using Rez. Hoping to make progress on that.
- Happy to announce first direct integration: AWS Deadline, put in a feature to allow a Rez resolve to be done at render time, hopefully list gets longer. Flip side to the coin is that since Rez is different from other projects: other projects are libraries being integrated into larger products. Rez is something we package other products with, hundreds / thousands of products, every ASWF project has been Rez-packaged at some point. Most DCCs / plugins / Python packages have been packaged with Rez. There are things that individual companies / products that are anti-patterns, such as requiring sudo, not publishing env vars you can use to control the package. Anyone who has done Rez packaging has come up with these challenges. Happy to talk to vendors about these packaging challenges.
- Have been discussing project challenges:
  - Difficulties blocking contribution
    - Documentation
    - Niche Domain
    - Testing / debugging / logging
  - User support
  - Top Project requests
  - Dependence on Allan
  - Attracting Long term contributors
  - Still early days of our ASWF process
  - Very little company Support
    - Deadline integration was welcome shock, few individuals working for companies have been given permission to contribute to Rez on company time. TSC contributors mostly doing it on their own time.
  - Lull in activity
    - 2-3 TSC members have had significant job changes
- Positives
  - Community Engagement
    - #rez channel has very high contribution, great activity, gives us a solid pulse check as to what’s important to rez community. Our git stats aren’t going so well right now, but the #rez channel shows how important Rez is.
  - Successful companies using
  - Flexibility
- Top requested features
  - “Provides”
  - Better Windows shell support
    - Good PR on behalf of Co3 that looks promising
  - Better rez-pip
    - Converts PyPI packages into Rez packages
  - Cloud package repositories
    - Top request, would be a lot of value
  - Some entities have patched Rez to shove that version into Rez, seems promising, but needs to be well architected
  - Caching-oriented
  - Robust starter rez recipe set
- Developments
  - Windows Shell Pathing PR
  - S3/ MongoDB PR + proposal being written
  - ?
- Questions:
  - Kimball: what about security for a cloud repository? JC: working on this, we don’t have all the answers yet, trying to reach out to as many people as possible. Amazon interested in participating in effort, might be interested in sharing resources. Kimball: have to deal with credentials, how long does it take to update a package when there’s a CVE. JC: not planning a central package repository yet, more a per company repo, but paving the way towards something else. Try to get rid of filesystem dependency, shared filesystem can be a bottleneck and administrative burden. Get rid of that dependency, put packages in S3, if later on want to support more workflows, we can build on that. Stephen: a couple of years ago, there was an idea around Rez and CI working group could have some intersection, maybe concept of CI working group helping package Docker containers, maybe a framework taking ASWF projects and building those as Rez packages. Don’t want to mix Docker and Rez approach, but being able to host Rez versions of ASWF libraries, has concerns around security, but the idea has merit. JF: could Rez be a plugin to Artficatory? JC: trying to build something that’s plugin based, want to still support filesystem approach, but support other tools as well. S3 as a plugin since that’s top request, but could even support an ASWF Artifactory repository, and use in CI
  - Larry: having a starter set of recipes, do you have a position if it’s worth making those part of Rez, or should projects come with an example Rez package.py for people who don’t want to create their own? Is it useful for Rez to make PRs into projects? Stephen: not sure if it makes projects to support their own package.py, Allan and I have started an effort to push the concept of having a starter set of Rez recipes, a sample implementation of everything that takes you from building IlmBase all the way to building USD. As well what extra you need to do to plug them into Maya, Houdini. Every studio would need to customize to suit their own needs, so not clear it would be portable. Larry: if you saw how studios need to customize the recipe, maybe that’s a concept that could be moved back into the configuration. Stephen: yes, how does this get everyone to a common denominator. A “common core” that people could base their stuff on. One of the big vision goals for Rez from Anders Langland was a prototype idea: a concept of a Rez Install method where packages aren’t just their payload, a package could be used to arbitrarily deploy and install a whole corpus of packages on the fly by reversing the dependency tree and building those on the fly. Part of the concept would be a studio able to deploy an entire setup based on requirements like Nuke / Houdini / Maya version, “I need a VFX 2023 compatible setup”, and it could figure out everything you need. “Provides”, “cloud packages” all lead to the same result. Something to look forward to.
ASWF Budget Presentation (Andrew Pearce)
- Budget Committee meets on Mondays before TAC, meet and discuss budget, what we’re going to do, where we spend and save money.
- We had projected a loss for this year, around $9K under budget this year. We are sitting on a large surplus, Board is considering what to do with that.
- Approving sources of funds with banks is tricky, it’s not like we’re going to create a self funded foundation. If there is a project that needs some funding, put together that proposal, bring it to the Board, and there are funds.
- One of the reasons this came to a boil was an issue with Slack charges. But if we could use Discord?
- Breakdown for 2023
  - LF General and Administrative: 9%
  - Staff, Travel & Board: 13.8%
  - IT Infrastructure and Staff: 40%
    - Hosting & Infrastructure (DPEL, GitHub Runners, JIRA / Confluence): 6.3%
      - $3000/month for DPEL
      - $1000/month for GitHub premium runners
        
        JF: I think the cap is $1500/month and potential desire to increase (no GPU usage costs yet)
        
        John: this is where the budget committee comes in, look at the run rate, and adjust accordingly. The budget committee doesn’t approve things, it recommends to the Board. New projects would be presented from the TAC to the Board.
      - $1000/month for other usages (JIRA/Confluence)
      - These are highly conservative estimates, expecting to be lower
    - LF IT service: 25.7%
      - LF Collaboration Services Medium Tier and LF Release Engineering Services Larger Tier
    - Licensing scanning: 2.6%
    - Technical Community Commons Platform (Slack): 3.3%
      - Slack Pro - plan for $32K based on estimates
      - Future: review with TAC to determine value
    - Diversity and Inclusion: 2.1%
  - Community Engagement & Marketing: 36.9%
    - Marketing & Social Media Staff: 10.4%
    - PR Agency: 5.0%
    - Marketing Operations and Tooling: 4.2%
    - Creative Services: 1.2%
    - Videos and Sizzle Reel: 0.5%
    - Open Source Days: 7.8%
    - Open Source Forum: 5.7%
    - Other Events and Tradeshow Participation: 2.1%
- Kimball: shouldn’t D&I be under Community and Engagement?
  - John: some historical background. It ended up there in the spreadsheet, could be moved to another category. To larger point, we’ve noticed over last couple of years that this group is efficient with its funding, it would be interesting exercise for the Board to see if we want to put this in the spend for events. They wanted to provide a reasonable amount of starting funding for D&I and let them decide how they want to address it. Andrew: despite where it appears where it appears in the budget, there’s still a rationalization of how this effort works with other efforts.
  - Eric: who is using LF IT and Release Engineering? We are critical of Slack, but it’s a small percentage compared to that budget line item. For the projects I participate in, Slack is one of our more valuable assets for collaboration. Eric E: DPEL has been using a lot of the IT RelEng Group. John: if you are asking less use the IT RelEng group? Eric R: is it more about an engineer that’s helping out setting things up? John: a lot of our model here is that we have a set of shared services used across project communities. It tends to ebb and flow over time. When DPEL was starting up, it was using a lot of Andy / RelEng resources. What we try not to do is to keep track hour by hour / itemized billing. At the end of the year, we try to figure out how much of the resources have been used. So more of a flat cost model, but it averages out. All our LF projects work this way, seems to be a pretty clear model from a planning perspective. Eric: it sounds reasonable to me, but would be nice to know what’s covered under that. Andrew: what controls do we have to control those costs. Eric E: for DPEL, it was hard to know what the expectations should be, hard to know how quickly something could be done. What services are we asking for these days, and how do we influence that. Is it mostly new projects coming on, setting up CI? John: also a lot of ongoing items, can probably pull a clear overview of the services. A lot of that lands with newer projects establishing infrastructure, then a bit of maintenance. We try not to look at it as a pure hourly rate, instead understand what the projects are trying to do, and adjust staffing accordingly.
  - JF: CI WG is a place where a lot of interaction with LF RelEng group happens. Centralized infrastructure. John: would be a good idea to get a one pager with the list of services, also anytime you file an IT support ticket that’s covered by that team. Carol: are there more things we should ask for.
  - David: adjustments can always be made, refined and improved. It took us a long time to get in front of you. Also what Andrew said at the beginning, besides this operating budget, we also have a surplus, we want to protect it and that it’s there when we need it, but TAC had mentioned many times that there’s need for more engineers, maybe we should hire engineers? At leadership forum, our revenue is matching is budget, we went a bit over but we re-adjusted. This is the budget that matches our revenue at this time. We can also try to generate more revenue, always welcome ideas on that front. When you have needs for your project, don’t hesitate to bring them up, we can consider them. Thank you Andrew for being our Treasurer, Darrin Grant will be the new Treasurer going forward.
  - Carol: Budget Committee, is that just for the worth, or should someone from the TAC join that? Andrew: don’t know if there are hard rules, so could be a good idea. Involvement from the TAC would be welcome. John: it is set up as a Board committee, so would need a charter change. Carol: it’s just an idea, but it might be a good idea for the TAC to have slightly more involvement, some of our questions come from just not knowing. Kimball: had intended to attend meetings, but hours make it hard to attend. Andrew: could Kimball attend since he’s a Board member? John: yes, that would be fine. Andrew: could adjust time for the timezone. Kimball: or could fine a way to delegate that to my alternate.
  - Eric: if we’re making decisions about adding projects, we probably should be responsible with understanding the financial capacity to support more projects. John: this is not an exercise of projects have to spend less. A lot of the desire here is to give some insight of how the planning works, the role of the Board is to be of service to the community. If I look at other foundations, the Boards take input from the community, what it needs, and figure out how to make it happen. The take away should definitely not be that projects need to reign in costs.
  - Kimball: thank you to Andrew for presenting, thank you everyone!