PyTorch Foundation: All You Need to Know.

As you have heard, Meta has finally announced the PyTorch Foundation. It took us almost a year to get to this place where we finally can release it (if you even can say “release” about things like the foundation). In this article, I want to outline why this is done and what this means.

Let’s start with the problem. For quite some time, Meta was a gatekeeper for PyTorch. Any changes (whether net-positive or net-negative for PyTorch) should go via Meta. Meta would be the one to say yes/no for all of such changes. Side note, the real motivation behind such gatekeeping is purely pragmatic: stability of the internal customers (you also can read more details here). A lot of internal teams depend on PyTorch. The moment external contributors can merge changes to PyTorch without reviews/tests from Meta, they might land something that will break some internal Meta services.

While for an average external contributor, this situation is de-facto transparent. Who cares if the reviewer is from Meta or not as long as PRs been reviewed, tests are executed, and everything working as intended? But it is an entirely different story for big companies. Big companies do not want to invest in technology/framework/solutions if they completely tighten them to other companies. For example, AWS has made MXNet its framework of choice, not TensorFlow, not PyTorch. It is hard to say exactly why, but one of the contributing factors, for sure, was that MXNet was a truly open-source framework. At the same time, TensorFlow was de-facto gatekeeped by Google, and PyTorch was gatekeeped by Meta.

So here we are. If we want some big players to be more incentivized to invest in PyTorch, it should be “truly open sourced.” They should be able to co-own it. And this is precisely what we are doing with PyTorch Foundation. PyTorch Foundation is a new entity that now has complete control of PyTorch.

But let me dive a little into what “full control” means. It includes the following sections:

• technical governance
• business governance

These things are deliberately de-coupled. The technical governance branch is in charge of:

• making key technical decisions
• review/merge in PRs
• etc

Technical governance will have only actual contributors in it. There will be no “companies” there. Business governance is deliberately de-coupled, so there will be no possibility to “buy your way in” to the technical governance. People in technical governance, such as core contributors, are folks who have earned the trust of the community. Rough high-level process of becoming a contributor can be found here.

Business governance will be in charge of:

• budget
• business decisions
• etc

The business governance will be in charge of paying bills. PyTorch Foundation will be running many enormously huge services, including, for example, a continuous integration system. It will organize processes and procedures, the business community, run go-to-market initiatives, onboard the big customers, and so on.

PyTorch is now your’s project as much as it is Meta. You can be the next contributor to any of the PyTorch models, and you now have a clear path to become an even core contributor if you wish.

As for the next steps, each module will establish its own processes of how to be adding new contributors and which right to be giving them. Here is, for example, the process for PyTorch Dev Infra. We do not want to micromanage operations for each module; therefore, they are free to define their own processes.