React Is No Longer Meta’s Project, It Now Has Its Own Foundation

React (the JavaScript library that runs most of the web, whether you have noticed or not) just left Meta. The move is technical, governance, and symbolic all at once, and most of the developer takes I have read miss at least one of those angles. I have been writing React since 2016, and I have been waiting for this announcement for longer than I expected to.

What actually happened

In late February 2026, the React team at Meta announced that React is moving out from under Meta and into a new independent foundation. The new foundation is governed by a board of representatives from companies that ship React in production, plus a few independent seats. Meta is still on the board, but it no longer has a controlling vote. The new foundation will hold the trademark, manage the RFC process, and employ the React core team.

This is not the first time a major open source project has moved out from under its corporate sponsor. Kubernetes did the same when it left Google. The Linux Foundation has been running on the same model for two decades. What is different about React is the scale. There are roughly 12 million developers who have touched React in the last year, and the library is on something like 40% of the top 10,000 websites. The governance change is happening in a system that is too big to fail in any reasonable timeframe.

The move also closes a long-running complaint from React developers. For years, the “open governance” promise of the React team has been theoretical. The team worked for Meta, took direction from Meta, and shipped on Meta’s timeline. That is fine when Meta’s timeline and the community’s timeline agree. When they disagree (and they have, several times, in ways I have personally felt at work) the community has had no formal recourse. The new foundation gives the community a vote. It is small, but it exists.

What this means for the average developer

For the first six to twelve months, nothing practical changes. The React API is the same. The license is the same. The release cadence is the same. The package on npm (the default JavaScript package registry) is the same. You do not need to update your dependencies, learn a new API, or migrate any code. If you have a React app in production, it is going to keep working.

The most useful way to think about the timeline is in three buckets:

• Short term (6 to 12 months). Same code, same APIs, same releases. Nothing for an application developer to do.
• Medium term (1 to 3 years). The RFC process becomes closer to the Kubernetes model, where SIGs (Special Interest Groups) actually have decision-making power. The community gets a real vote on the roadmap.
• Long term (3+ years). The foundation outlasts any single corporate sponsor. The bet is that the governance structure is more durable than the current arrangement.
• Unknown. What the foundation does with the React Native and React Server Components workstreams. Those are the two codebases that have the most corporate involvement, and the foundation’s stance on them will set the tone for everything else.

Over the medium term, the RFC process is the part that changes the most. The React RFCs (proposals for new features, posted as pull requests on the React repo and debated in the open) have been mostly theatrical for the last five years. The team took the feedback that was aligned with their plan, and the rest of the discussion went into a void. With an independent foundation, the RFCs become closer to the Kubernetes model. If you have ever wanted to push back on a React design decision and felt like the conversation was a monologue, that is what is changing.

Looking further out, the foundation is the part that matters. Foundations can outlast the companies that fund them. The Linux Foundation outlived the dot-com boom. The Apache Foundation outlived the early web. The React Foundation, if it works the way the founders intend, will outlive Meta’s interest in React. That is the bet.

What could go wrong

The history of corporate-to-foundation migrations is mixed. The Node.js Foundation merged with the JS Foundation to form the OpenJS Foundation in 2019, and the result has been mostly fine, with the occasional governance dispute. The Angular project has been inside Google for over a decade and shows no signs of moving, and that has not stopped it from being a popular framework.

The risk for React is not that the foundation collapses. It is that the foundation becomes a paper tiger. A foundation that exists in name only, where Meta still calls the shots but with a layer of meeting minutes in between, is worse than the current arrangement. The community gets the appearance of independence without the substance. The board structure, with representatives from Vercel, Microsoft, Amazon, and a handful of smaller companies, is designed to prevent this, but the design is on paper. We will see.

Another risk is fragmentation. The React community is large enough that a competitor (a “React-compatible” library, or a fork) could plausibly emerge if the foundation strays too far from community expectations. The history of forks is not encouraging for the forked project (see: LibreOffice and OpenOffice, or MariaDB and MySQL), but the threat of a fork is itself a discipline mechanism on the foundation. The foundation will behave better because a fork is possible.

What I would tell past me

If I could send a message back to the version of me that wrote the first React component in 2016, I would say three things.

• Pay attention to governance, not just the API. The technical changes in React over the last decade have been incremental. The governance changes are what determine what the next decade looks like.
• Do not let one company control your stack. The work of moving from “Meta’s project” to “the foundation’s project” is the work of making sure no single company can break your stack by changing direction.
• Watch the RFC process, not the marketing. The blog posts from the React team have always been aspirational. The RFCs are where the actual decisions live. With the new foundation, that is more true than it has ever been.

Trade-offs

React leaving Meta is not free. The foundation needs to be staffed, and that means a non-trivial portion of the React team’s time will go to governance work that did not exist before. The initial foundation team is funded by member dues, and the dues model is the part most likely to surprise developers. The founding members pay annual fees that are not public, but the numbers are in the seven figures. Smaller companies that want a seat at the table are going to be priced out.

The transition is also going to introduce some short-term churn. Releases might slip, RFCs might be re-opened, and the documentation site is being re-orged. None of that is catastrophic, but it is going to cost teams that are mid-migration a few weeks of attention.

In our case, the trade-off is worth it. We have three React apps in production and a fourth in the planning stages. The current arrangement, where Meta owns the trademark and the team, has been working well enough, but the long-term bet is that an independent foundation is more durable than a single corporate sponsor. The short-term disruption is a price worth paying.

Your math will be different if you are running one React app, have a small team, and do not care about long-term governance. The transition is going to be a non-event for you. If you are a 50-person engineering org with five React apps, the foundation is going to be something you pay attention to.

If you are deciding whether to start a new project in React, the foundation news is a small positive. Not a reason to switch from Vue or Svelte or whatever you are using, but a small reduction in the long-term risk of betting on React.

Bottom line

The foundation is the right move. The question is whether the foundation works in practice, and we will not know that for a year or two.

In the meantime, keep using React. The library is the same library. The team is the same team. The roadmap is the same roadmap. The change is structural, not technical. The thing that broke is the part that was supposed to be unbreakable.