A couple of older PRs that should be merged if no comments
OpenFX Project Review (Gary Oberbrunner)
One of the OpenFX TSC members
A relatively small and mature project
GitHub activity seems to be already around 2x to before we joined ASWF
Topics
Organization Status
Contributors
Users
Visitors
Project Status
Website
Github
Tech Initiatives
Outlook
Focus Areas
Needs
OpenFX is an open standard for creating VFX plugins. It allows plugins (shared libraries) to interface with host applications, giving artists thousands of new tools and capabilities. It was created in 2004, and has evolved to become an industry standard under the ASWF
First Year under ASWF, joined around SIGGRAPH 2022
Organization Status
Stats:
Contributors
6-8 people attend every TSC, sometimes we get 10-12
Only 3 github committers, and 4-6 reviewers, need more!
Github users: 483 clones, 334 unique cloners (first fortnight of June 2023)
GitHub visitors: 594 views, 102 unique visitors
(no website stats currently)
Looking at a new Wordpress based website, existing was Ruby on Rails, nobody could update it, snapshotted it and made a static version, it looks like it’s from the 90s. Getting help from LF on this.
Monthly TSC meetings are solid, reliable, helpful and well attended
Mailing list: 42 members
Slack: 98 members (now our primary communication channel now), up from 48 in October 2022
Discord: 43 members
Much improved from twice yearly meeting cadence before joining ASWF
Outreach has improved, but would like to see more 2 way communication. Right now Slack is mostly just meeting updates
Updates
Old Association is now dissolved
Github is now migrated under AcademySoftwareFoundation
New website in progress (expecting design drafts this month, go live by SIGGRAPH)
Copyrights and IP all updated
New logo
Discussion
We are starting to move much faster than we did pre-ASWF. Monthly meetings help a lot, and the ASWF’s resources really help offload the admin work, as well as helping set direction and give us goals to reach for
But we’d like to go even faster if we can
We will always be slower than some open source projects because we have major commercial users, and because OpenFX is a mature plugin standard, so we need to get buy-in from both shots and plugins before committing a change to the standard. But we can do better around release engineering and support libs.
We’re trying to pull people together and get consensus on how to extend OpenFX both into new areas and deeper into existing use cases, to ensure OpenFX is the standard for visual effects for many years
Color management is a great case study: being part of ASWF has enabled us to work closely with OCIO to define how effects and host apps should communicate color information (break the assumption that image buffers are just “linear” or “video”). We hope to do the same thing with OTIO to help transport effect definitions in timelines in a portable way.
Project Status
Tech
GPU support for Metal, and OpenCL in addition to CUDA: complete (98%). Vulkan support is on the list
Overlay drawing support for non-OpenGL hosts: complete
In Process:
Conan builds
Automated CI builds
Automated release process
Color Management: use OCIO
Improved spatial clip management
Outreach
Working with other ASWF groups: OTIO, OpenColorIO, CI WG
OTIO: helping define effect definition schema
OCIO: using that to specify clip color spaces in OpenF
CI: helping set up CI and Conan
Non-ASWF groups: ASC and SMPTE re “framing decision lists”
Open standard for recording framing decisions, analogous to EDLs but for spatial framing (cropping, pan & scan, etc)
Outlook
Focus Areas
Adding color management - our top priority right now
Adding plugin and host example and test code for all new features
Solid CI and release process
Helping everyone migrate away from OpenGL (GPU buffers and DrawSuite)
Support Vulkan image buffers, as demand grows
Supporting OTIO’s effect definition standard
Needs
More contributors / committers / reviewers
More input from new people: same group of people for a very long time. We’re friendly, we’re open, anyone can write an OpenFX plugin in a day, and it works on a dozen host applications. Would love to communicate this excitement, get more people on board.
More git and github expertise among the TSC
Help to support our example plugins, and plugin and host support libs. We do a good job of managing the standard, but we (the TSC) sometimes forget about the sample code, important to new users. Making a project to get the support libs modernized, showing off all the latest features. Would be great to have some other people interested in helping with that.
Better documentation of host feature support. OpenFX is a “self describing” API, plugins can query at runtime what host supports, but that hasn’t been written down anywhere. Encouraging host developers to fill in chart on Wiki.
Ideas
Would folks be interested in ASWF open source events at NAB or IBC?
Since we’re in the 2D post space, most of our users and contributors are more likely to attend NAB than SIGGRAPH. Joshua: OTIO is also has a lot of people who tend to attend NAB. Also we’re interested in the FX schemas, especially now that Resolve supports OTIO, and is proposing metadata for FX.
Could we create a job board to match projects with developers? We sometimes get requests on our Discord “is there anyone available to write a plugin”? Do other projects have a job board? Wave: in DPEL we have a wishlist of assets we’d like to have. Carol: OCIO has both NAB and job board interest. Wave: no central place to go, giving a talk about open source at Apple, a big question is “how can I help”? Would be good to have some kind of coordinate list of ASWF needs for contributions that could be pointed to.
Carol: how do we get people who are interested in contributing pointed to the right place. Dovetails with Dev Days. Every project should have needs in a visible place (with their roadmap). Have a spot on your web site. OCIO doesn’t do this explicitly (yet?).
Carol: the “best” way to get involved with a project is to start using it / have a need to use it, and then have a list of needs ready. All projects deal with the same issues Gary is talking about. Dev Days should help with this, but ASWF needs to talk about engagement.
Wave: you made an interesting point with regards to potentially onboard someone quickly, here’s how you can write a short plugin using the API. Don’t know that most of the projects have the ability to do that, maybe that will pull people into the project. Once you are interested in the use case, you can get interested in contributing to the actual API.
JF: are you seeing more input from host applications? Gary: seeing a bit more of this now that we are part of the ASWF, would like to see a lot more of it. Haven’t seen contribution from Flame, Natron, there could be a lot more. If anybody has ideas on how to make it clear that things can change. The color management stuff comes from those frustrations. Eric: a tutorial for writing a plugin and using with Resolve might be cool - Resolve is widely used and anyone can grab a copy for free.
David: thank you for suggesting the idea for NAB / IBC. We now have enough projects that have an interest in those markets, we will look at doing the right size of activity at those events now that we have started expanding our reach with the Beer of a Feathers event in London.
Dev Days update - Carol Payne
Originated with the idea of a ASWF Hackathon, but moved to name of “Dev Days”. TAC and board met at last year’s SIGGRAPH, ASWF + company sponsored hackathon. Lots of junior / intermediate engineers at our companies who are interested in participating in open source software, but haven’t had the opportunity to get involved. This level may be a good way to increase our contributor base. The people coming out of SLP don’t necessarily have the background to contribute to our projects.
At first targets our member companies, if someone is already working at our member companies, they typically already know what a pipeline is, how projects are used within a pipeline…
Want to send to companies to gauge the level of interest, want to send next week, so you have until next week to provide feedback, either on the document, or directly.
You might get that email as the representative for your company, so you will need to forward this within your company to determine level of interest.
In the document there are 3 different roles:
Project maintainer
Company Lead
Dev Day Participant
Want each project that participates to commit to this. Would like people interested in participating to raise their hands, either now or later in Slack. We would like to schedule a separate meeting, what does it look like from your project’s perspective. Nothing is set in stone, participation may look different for different projects. If you as a project maintainer are interested, please reach out to me.
Any company that decides they want to participate, expect a Company Lead: could be TAC members, but could be someone else. Will take some organization, tracking people down, dealing with legal. So TAC representatives should be involved, but you don’t have to the Company Lead for your company.
We need to take action quickly, and commit as to whether we do this in October. Lots has to happen to make this a successful project, in particular not every project has a CLA in place yet. If we commit to this, we will announce this “fully” at Open Source Days at SIGGRAPH.
Rachel: to really make this happen will require a lot of support throughout the TAC and projects.
Larry: I bet that in everyone of our organizations, there have to be 3 or 4 junior engineers how are intrigued, but may not even know the projects they have the opportunity to participate. We should try to identify these people, try to pull them in, it’s our responsibility to provide growth opportunities, involvement with these projects gets your fingers into projects that are used throughout the industry, interact with senior people at your company and others, and benefit from networking / career development. We should be looking at this to help the career development of our more junior engineers.
Carol: I want to co-chair this effort, that helps events be more successful, so if someone is interested in co-chairing with me, please let me know. If I don’t hear from anybody within next week or so, that might limit the the desire to move forward with this project.
Security Working Group (Jim Helman)
In January brought proposal for Security WG. As you move to the cloud, can’t rely on perimeter security. More software needs to become security aware, interact with authentication and authorization. Different from managing packaging, scanning for vulnerabilities.
Some discussions on Slack in February, led to a broad charter, there was some overlap with Security work in CI WG, put forward a much narrower charter on Slack
Raising awareness of new runtime security models
Implications for ASWF projects
Consolidate and share best practices for implementing those
Someone has been doing a lot of security integration, did a project that uses OTIO, OpenAssetIO and OpenRV in a demonstration. We found that some of the applications that needed to be security aware were not. We provide a small patch / workaround. There should be framework code that could be reused, like “OpenFX for security”. Would be good if the WG could explore if there could be shared goal that could be reused.
Non goals: not trying to maintain code, or duplicate security aspects of CI WG
Deliverables would be documents
Reaching out to cloud providers to provide a good security technical resource.
Proposals for other projects, such as framework code, that the group may determine are needed.
If we can get critical mass, we could have a proposal back to the TAC to see if it’s something the ASWF wants to do.
Kimball: is there a deliverable in there to help projects how to test their project against a security baseline? Jim: having code reviewed and assessed by security experts is important. Advice on best practices for security assessments will be added.
Larry: don’t overestimate our current knowledge base. I guess that if you want to leaders of our current projects, they wouldn’t know if their project should consider authorization / authentication angle to things. They may not even know if it’s something they should build into their project. Don’t be afraid to treat us as if we know nothing of the topic! It’s far out of our expertise domain. Even very experienced developers have worked “inside the firewall”, authentication is all new, so starting at the beginning makes sense. Jim: emphasize educational aspect, maybe training videos.
JC: thanks for keeping this alive, I appreciate you coming up with this idea. I might want to expand the scope of point 1: it’s not just good for users, but also for the project. Authentication is used in OpenCue, and probably soon in Rez, would be good to gather existing authentication needs for projects. Jim: once we have a group of people who are interested, will update the proposed charter, discuss on Slack, maybe then we can have a call to flesh out remaining details.
Maybe also reach out to DCC vendors, we have this “Common Security Architecture for Production” based on Zero Trust model, the DCC vendors are very much engaged on that, so may be able to get engagement from vendor security teams.
Cary: We could designate a specific project to get a full audit, which would be less abstract. Guide a project through to the state it needs to be, that would inform the rest of us as to what we need to do.
Jim: we’ve already created a patch to OpenRV to get some of the security we needed for our demonstration, could see packages that need to support plugins, could be a good starting point.