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 lo...