#1526: Allegations that Meta’s OVRPlugin is Undermining the Spirit of OpenXR by Blocking Non-Meta Headsets on PCVR.

In a series of posts from February 8th to 11th, open source developer Matthieu Bucchianeri started making allegations that Meta's OVRPlugin is blocking non-Meta OpenXR runtimes, thereby undermining the open and interoperable spirit of OpenXR. He claims that "the OVRPlugin takes intentional precautions to exclude non-Meta platforms. This means that XR content developed with OVRPlugin will only work with Quest Link, and it will not work with any other runtime." Bucchianeri's allegation is that if a PCVR game includes Meta's OVRPlugin as their OpenXR middleware and doesn't implement the counter-blocking measures that he details, then PCVR users will only be able to use a Quest headset with Quest Link while other non-Meta headsets like "Pimax, Pico, Varjo, Vive" will be blocked, even if they have conformant OpenXR runtimes. Bucchianeri has validated these blocking counter-measures, and he says, "as proven with many applications using OVRPlugin with counter-measures enabled, these applications can run on a conformant OpenXR implementation." Not very many XR developers are willing to speak about these issues on the record, but I did manage to record a Voices of VR podcast interview with Virtual Desktop's Guy Godin who was able to independently corroborate many of the core allegations from Bucchianeri. Godin collaborated with Bucchianeri on the Virtual Desktop OpenXR (VDXR) runtime, but has also been receiving many complaints from PCVR users around Meta's OpenXR non-compliance issues, especially with games that launch both on Quest and PCVR and use Meta's OVRPlugin. Godin told me that games will work fine natively on the Quest, but any non-Quest headsets or if they aren't using Quest Link will be blocked on the PCVR version, unless the developer specifically implements anti-blocking counter-measures detailed by Bucchianeri in his technical write-up. It appears as though OpenXR conformance from the Khronos Group only pertains to the actual OpenXR runtimes on the hardware, but headset manufacturers are able to create their own SDK plug-in middleware that interfaces with OpenXR that doesn't have the same conformance requirements. It appears as though Meta is able to technically maintain their OpenXR runtime conformant status because it does not apply to their OVRPlugin middleware SDK solution, and Bucchianeri is claiming that Meta is undermining the normative standards of interoperability by not following the best practices from the Khronos Group. He says, "For the past several years, Khronos has come up with best practices and solutions to develop OpenXR applications and maximize cross-vendor and cross-platform interoperability. Khronos has asked XR developers all over the world to follow these best practices, however - Meta - the largest vendor in Khronos is refusing to follow these best practices." Bucchianeri is also claiming to have had private communications with Meta confirming that these were deliberate and intentional changes. He says, "This is not an accident: this concern was reported to Meta early in 2024 via official means in the Khronos group. Meta acknowledged purposedly blocking other platforms from running OpenXR content at that time." I was able to confirm in my discussion with Guy Godwin in this Voices of VR podcast episode that he also believes that these were deliberate and intentional changes to undermine the spirit of OpenXR. Part of why Bucchianeri was blowing the whistle is because the Khronos Group had not been taking any action against Meta. He describes Meta's actions as "reverting many of the improvements to the developers and users ecosystem that Khronos has spent time, money, energy into solving for the past 7 years." He says, "Unfortunately, since 2024, Khronos has refused to take actions to stop Meta’s OVRPlugin destructive initiative towards the PCVR ecosystem. By not taking any actions to resolve the issues created by Meta’s OVRPlugin, Khronos is sending the message that OpenXR is no longer a universal solution for cross-vendor and cross-platform support, that passing the CTS [OpenXR Conformance Test Suite] and being conformant mean nothing (conformant runtimes are precluded from running OpenXR apps), and that the OpenXR logo and trademark no longer carry the same significance as before in the PCVR ecosystem." Bucchianeri was not happy with the lack of a public response from The Khronos Group, and on the evening of February 8th, 2025 he posted a GitHub issue requesting to the OpenXR-Docs to "Please remove my name from the specification and public documents." He spoke publicly about this issue for the first time by saying, "Khronos was once an organization that worked relentlessly to make OpenXR a cross-vendor, cross-platform standard of high quality. Unfortunately, since 2024, Khronos has refused to take actions to stop Meta's OVRPlugin destructive initiative towards the PCVR ecosystem... I do not wish to see my name - Matthieu Bucchianeri, an independent developer - associated with an organization that has turned its back on developers, that promotes discrimination against small vendors/developers and that encourages practices that go against the foundations of the original OpenXR brand." Bucchianeri also posted an issue to the OpenXR-Inventory to remove his OpenXR products from the Khronos repository saying, "To protest against Khronos complacency and failure to take action to end Meta's attacks to minority vendors, small developers and against the PCVR ecosystem through their OVRPlugin." He updated his initial GitHub post on February 11th after he had posted his more detailed technical breakdown by saying, "For an overview of how OVRPlugin has been violating the OpenXR best practices since 2023 - see this technical description." After nearly two weeks, the Khronos Group felt enough pressure from the OpenXR community about this issue that they issued a rare public statement on February 21, 2025 titled "Statement from OpenXR Working Group in Response to Community Discourse on the OVRPlugin from Meta." But this title was the only explicit mention of Meta, and it is a bit of an ambiguous statement that does not appear to directly address the issue. They say, "The Khronos OpenXR Working Group recognizes the challenges developers have faced with legacy APIs and platform-specific behaviors that limit XR application portability. The Working Group is dedicated to evolving OpenXR by incorporating vendor extensions into the core specification and continues to enhance platform interoperability. Today, three major engines - Unity, Unreal, and Godot - support building OpenXR applications that are compatible with multiple vendors' OpenXR conformant devices, provided vendor-specific features are avoided." The Khronos Group seems to be saying that if you want an OpenXR middleware solution that is "compatible with multiple vendors' OpenXR conformant devices," then check out the OpenXR plug-ins from either Unity, Unreal, and Godot. The implications of Khronos's statement responding to "community discourse on the OVRPlugin from Meta" is to simply not use Meta's plug-in. But Bucchianeri is also claiming that Meta is going out of their way to discourage users from using any other OpenXR plug-in aside from their own by giving a variety of different scary warning messages. He says, "Meta has crafted a user experience in the game engines that forces developers to select OVRPlugin while making it difficult to implement fallbacks to standard OpenXR support. In Unity for example, a developer selecting OpenXR support after having enabled OVRPlugin will be prompted with a message declaring “incompatibility” and reverting the selection of plugin to OVRPlugin exclusively." I was sent the specific warning message from a VR developer when they tried to use Unity's OpenXR Plugin. "This APK includes libUnityOpenXR.so, but not libOVRPlugin.so. The Unity native OpenXR plugin is not yet fully production ready. If you are experiencing performance or compatibility issues, please enable the Oculus XR plugin (and disable the OpenXR plugin) in your project." You can find this specific warning message shared in a forum here in May 2024, and an earlier version of this message from March 2024 that says, “Unity’s OpenXR plugin is not recommended when using Oculus SDK, please use Oculus XR Plug-in instead.” I spoke with Virtual Desktop's Guy Godin about all of this in this episode of the Voices of VR podcast (see full transcript below), and he identified Meta's Integration SDK v51 released on April 25, 2023 as "when games started to no longer be compatible and break when played with Virtual Desktop." I reached out to Meta on Wednesday afternoon to see if they had any public comment about any of these OpenXR controversies, but they have not replied to my inquiry at the time of publication. If Meta does decide to make a public statement, then I'll add it as an update. The last public statement from Meta about OpenXR that I could find was from the press release of OpenXR 1.1 on April 15, 2024 where Meta was quoted as saying, "Meta has been committed to building an open, cross-platform standard for the XR industry since the inception of the OpenXR standard in 2016”, says Jonathan Wright, senior staff engineer at Meta. “The OpenXR 1.1 release is one more step towards making it easier for developers to build XR applications. We continue to support the evolution of the OpenXR standard as we work to build an open and interoperable XR ecosystem.” Even though Meta was publicly supporting OpenXR as late as April 2024, according to Godin's and Bucchianeri's allegations Meta may have already been starting to undermine the spirit of OpenXR for a year going back as early of April 2023. The public statement from Khronos Group acknowledges the controversy from community about Meta's OVRPlugin, and suggests using the game engine plug-ins if you're looking for a OpenXR plug-in that is "compatible with mult