In the case of Linux, this is done by the Linux Foundation. Some VFX-relevant open-source projects, such as OpenEXR or OpenVDB, are now under the umbrella of the Academy Software Foundation (ASWF), which in turn is under the umbrella of the Linux Foundation.
Anyone working with VFX will inevitably also directly or indirectly use open-source technologies, such as OpenEXR for exchanging images with high bit depth in the scene-referenced colour space, OpenColorIO for colour management, or OpenImageIO for reading and writing numerous image formats. These components are usually invisible to the user as parts of larger software, such as The Foundry Nuke, Autodesk Maya, or Blender. Although these open-source projects are used by many companies, the development of the projects was mostly in the hands of individual companies. For example, OpenEXR was under the control of Industrial Light & Magic (ILM), Open Shading Language (OSL) was managed by Sony Pictures Imageworks, and OpenVDB was overseen by DreamWorks.
A Question of Trust
This situation was unsatisfactory for other market participants, as they did not trust each other. This is also one of the reasons why all these projects are open-source and subject to extremely permissive licenses. Disney, for instance, would never use proprietary software from DreamWorks, but it would use OpenVDB as open-source software under the Mozilla Public License. However, trust would be further strengthened if the projects were managed by a neutral third party. This would also address the issue of projects becoming orphaned when a central developer changes jobs.
Enter the ASWF
The Academy Software Foundation (ASWF) has taken on this role, and under the auspices of the experienced Linux Foundation, it has successfully persuaded competitors such as NVIDIA and AMD, DreamWorks and Weta Digital, as well as The Foundry and Adobe, to work together. Jean-Francois Panisset explains how this was achieved in an interview.
DP: I‘m here at FMX with Jean-Francois Panisset (is.gd/jean_francois_panisset) from the Academy Software Foundation (ASWF). It‘s basically an umbrella foundation for a lot of open source projects that are currently used in visual effects. But why do you need an umbrella foundation for those projects at all?
Jean-Francois Panisset: Many foundational projects, like OpenEXR, OpenColorIO, and OpenVDB, were originally developed by major visual effects studios and later open-sourced. OpenEXR, for example, was open-sourced around 2003, and for a while, everything worked well — other studios could download the software, and vendors could integrate it into their products.
However, as time went on, the original creators moved on to new roles, left their companies, or even left the industry entirely. This led to a lack of active maintenance, and these projects began to stagnate. Bug reports went unaddressed, pull requests weren’t reviewed or merged, and in some cases, the projects couldn’t even be built anymore due to a lack of automated CI builds. It became an industry-wide problem. Recognizing this issue, discussions began on how to maintain these projects long-term and create a sustainable ecosystem. CTOs from major studios and software companies held meetings, conducted surveys, and explored solutions with organizations experienced in setting up foundations.
The Linux Foundation emerged as the best fit, having successfully created similar initiatives, like the Automotive Linux Foundation, which brought together competing car manufacturers to collaborate. This led to the decision to establish the Academy Software Foundation (ASWF) as a sub-foundation of the Linux Foundation, providing a structured environment for professional open-source development, ensuring projects wouldn’t collapse when individual contributors moved on.
Since its formation, the ASWF has expanded from the original three projects to 14, all of which are now active and well-maintained. One key advantage of the foundation is its legal framework, which allows competing companies to collaborate on these projects without concerns about antitrust issues. This neutral, legally protected space enables a higher level of cooperation than a three friends developing together – competing companies need to have a neutral space to collaborate.
DP: How do you support developers looking to contribute?
Jean-Francois Panisset: The ASWF offers a range of resources to support project development. We provide collaboration tools like a paid Slack instance, Zoom, and scheduling platforms to keep teams connected. Our GitHub organization is at the enterprise level, giving projects higher build-time limits, and we also have technical support through the Linux Foundation’s release engineering team for any GitHub issues.
We cover paid infrastructure like Docker Hub to avoid throttling on container pulls and offer more powerful build systems for projects that need extra memory or CPU, like OpenVDB. Projects with GPU-enabled test suites can also access paid GPU runners, which aren‘t available for free on GitHub. While development still follows the open-source model, working publicly on GitHub, these resources help avoid roadblocks and make the process smoother. The way you develop software within ASWF is really still the open source way – you get access to all these extra features that just facilitate the development process and mean you don‘t get blocked because “oh we don‘t have access to this”.
DP: Let‘s say I found a bug in one of your projects and I want to file a report or maybe I even have a fix. Usually it can be quite daunting to approach a project. I think you have some on-boarding process?
Jean-Francois Panisset: It varies by project, but most follow a standard process since they’re all GitHub-based. If you find a bug, the first step is to create a GitHub issue. All projects monitor these, and their technical steering committees review and prioritize new issues. If you also know how to fix it, submitting a pull request (PR) is encouraged. Some projects require signing a Contributor License Agreement (CLA), which assigns ownership of the code to the project, preventing IP disputes. The Linux Foundation provides an easy process for this. Individual developers sign an ICLA, while companies can sign a corporate CLA, allowing their employees to contribute without additional approvals. Though it may seem like legal paperwork, it can simplify contributions, especially from large organizations.
Other projects have a simpler process, requiring a Developer Certificate of Origin (DCO), where you certify that you wrote the code. Before submitting a PR, it‘s always good to engage with the project to confirm how they‘d like it implemented. Even if a PR needs adjustments, the steering committees ensure that issues and contributions are addressed.
for content management OpenAssetIO and the programme collection for the playback and review process Open Review Intiative are currently there.
DP: What if we’ve made a larger change, like customizing a library, and want to start small before submitting the bigger contribution?
Jean-Francois Panisset: The concept of a “good first issue” is key to project maturity. Projects are encouraged to flag these issues to attract new developers. While some projects require domain-specific knowledge—like contributing to OpenColorIO’s colour transform engine, which is suited for colour scientists—there are still many contributions that don‘t require specialized expertise. By tagging beginner-friendly tasks, newcomers can browse the backlog, find something they can tackle, and submit a pull request.
Last year, we introduced “Dev Days,” a 48-hour event, similar to a hackathon, where developers can get real-time help with setting up their environment or validating their approach. It’s a great way to onboard new contributors. Facilities are also participating by encouraging their engineers to work on open-source projects. This helps studios prevent knowledge loss — especially when only one developer knows certain systems like OpenEXR — by getting more developers familiar with key projects.
There‘s a tool called Clotributor, developed by the Cloud Native Computing Foundation (CNCF), that aggregates “good first issues” across multiple projects. You can search for projects you‘re interested in, and it will suggest issues flagged for beginners. It‘s not limited to ASWF; several foundations use it. Some projects have received PRs from developers outside their field who found the issues interesting. It‘s in every project‘s best interest to attract new contributors, even if it‘s just for a one-off fix — you‘re still better off than before.
DP: The list of projects on your umbrella is pretty impressive and every artist in the industry is using them actively. What‘s the rationale for the organizations behind the projects to open source their technology in the first place?
Jean-Francois Panisset: So, obviously, I don‘t speak for any of those organizations, but there‘s multiple motivations. The first one is: don‘t underestimate people wanting to do the right thing, and realizing that in our industry being able to collaborate is important. Maybe there‘s that, but also almost a business reason, because today there‘s very few projects that are done at only one facility. So, if I as a facility have this great proprietary data format that no one else know, that‘s not really helpful. How am I going to exchange data with other facilities? So open sourcing my component and “hoping” it becomes the de facto industry standard is great because I don‘t have to rewrite all my internal software.
Also, I don‘t have to carry a hundred percent of the burden of maintaining that software, because other facilities have an incentive to help develop and maintain that software. That‘s partly why the list of projects in ASWF are interchange formats – which are handling how you move data around between projects and departments and facilities and vendors. There‘s also the idea that I would love software vendors to support that format – and the way to do that is to make sure that my format becomes a de facto standard and the implementation becomes the de facto implementation.
Also if they can easily adopt the implementation into their software, it becomes more likely – who wants extra work, right? And in turn this would attract and retain software development talent – which is always a challenge and providing the opportunity for your engineers to not just “work internally” but also to contribute to a greater community will demonstrate their value to the community. And that‘s good for the company in the long term, because you‘ll have happier engineers who will be more productive.
Because, as an engineer, if you‘re exposed to not just the way things are done in your company but the way things are done elsewhere,you learn more and you become better at what you do. Open Sourcing as a way to make your engineers more productive and attract talent. I wouldn’t want to work where all the work is just internal – and with an Open Source Development, you will show the fact that you‘re not just a great studio that makes great visual effects, but you also have a great technical culture. There‘s no better way to advertise to professionals that than through open sourcing some of your internal technologies.
