Please remove my name from the specification and public documents

[mbucchia]

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. Meta's OVRPlugin is a self-proclaimed "OpenXR" middleware that intentionally blocks the use of OpenXR on non-Meta platforms. Developers using this middleware are misled into creating applications that will only work with OpenXR when the end-user uses Meta's own platform, effectively excluding small vendors from enabling OpenXR content on their platforms and cornering small developers to write Meta-exclusive content. Refer to GitLab internal issue #2279.

Instead of relying on the processes and metrics that Khronos has been working on since 2017, Meta has unilaterally decided that the only form of conformance that matters is the one that Meta dictates and that the only thing that matters to run an OpenXR application is whether the end-user is running Meta's platform. By not taking any actions to stop Meta's targeted attacks, Khronos is sending the message that OpenXR has given up on cross-vendor and cross-platform support, that passing the CTS and being conformant mean nothing (conformant runtimes are precluded from running OpenXR apps), and that therefore, the OpenXR logo and trademark are losing their credibility in 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.

Please remove the following occurrences of my name: https://github.com/search?q=org%3AKhronosGroup+repo%3AKhronosGroup%2FOpenXR-Docs+bucchianeri+&type=code

EDIT 2/11/25: For an overview of how OVRPlugin has been violating the OpenXR best practices since 2023 - see this technical description.

[rpavlik-bot]

An issue (number 2456) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2456 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.

[KhronosWebservices]

Dear Matthieu,

We would like to express our sincere appreciation for your long-standing contributions to OpenXR and the broader XR ecosystem. Your dedication to the principles of portability and cross-vendor compatibility has been invaluable, and we are grateful for your commitment to these ideals.

We regret that OpenXR has not met your expectations, and we understand that this has led you to take a step back from our community. We want to assure you that we take your concerns seriously and appreciate the opportunity to reflect on how we can improve.

Historically, the OpenXR working group has focused on standardizing the interface between a runtime and an application written directly against the API, with input from game engines along the way. While we have not traditionally considered middleware packages like engine plugins within our scope, we recognize the importance of ensuring that these components align with the goals and methods of the API. We are actively exploring ways to address this gap and ensure that plugins provided by runtime vendors support the principles of OpenXR.

We value your expertise and perspective, and our door remains open should you wish to re-engage with Khronos in the future. We will honor this request with the next spec release. We hope that you will consider continuing to contribute to the OpenXR community and help us shape the future of XR technology.

Best regards,

Khronos OpenXR Working Group

[mbucchia]

We would like to express our sincere appreciation for your long-standing contributions to OpenXR and the broader XR ecosystem. Your dedication to the principles of portability and cross-vendor compatibility has been invaluable, and we are grateful for your commitment to these ideals.

While I appreciate your words @KhronosWebservices, your actions never followed.

Even your latest "statement" ignores the core of the issue that I have reported a year ago: the fact that OVRPlugin - used by dozens (hundreds?) of developers - is broken in an unacceptable way that is detrimental to other vendors. Your statement also ignores the solutions I have proposed for a year (fixing the OVRPlugin), just like you have ignored my messages to the group while I was a member. The PDF you shared, showing how to create a Unity/UE project without OVRPlugin, are good but they do not reflect the typical developer path (in real life) where they are starting from a standalone Quest project (with OVRPlugin) and migrating to PC. There is only one fix for that scenario, and it is a fix in OVRPlugin. It's not even a fix, it is just common sense for Meta developers when they employ the OpenXR API.

I don't buy that you have "sincere appreciation for [my] long-standing contributions", "value [my] expertise and perspective" and that "we take your concerns seriously and appreciate the opportunity to reflect on how we can improve" when all you have done since Apr 2024 is ignore the real issue, letting it grow further, and ignore the feedback I provided about holding Meta accountable to fixing their middleware.

You and Meta are resting on your laurels.
Valve has taken action with their compatibility mode.
Virtual Desktop has taken action with their (our) OpenXR runtime and API layer.
I have taken action describing very clearly the issue (and fixes) in GitLab issue #2279.

The users have spoken: they don't want to be forced to use Meta's OpenXR runtime on PC that is only advertised to be developed and conformant with the Oculus Rift S, a headset released in 2019.

I will not be wasting any more time trying to explain the issue to you, but I will leave you with a thought (same I shared in Apr 2024, same I shared in Nov 2024 and Dec 2024):

If Meta - the dominant player in the XR industry - is not capable of producing a software with OpenXR that actually fulfils the promise of OpenXR cross-vendor portability, how do you expect to have any sort of credibility when asking 3rd party developers, indie developers and hobbyist developers to use OpenXR to write cross-vendor code?

I will copy-paste the latest statement from my website:

WHAT DOES A WIN-WIN-WIN ECOSYSTEM LOOK LIKE?

Step 1): Meta to fix the 2-3 OpenXR conformance issues in their plugin (see the technical explanation). This isn't difficult - Meta is part of Khronos and knows exactly how to use and properly handle the API. Having Meta fixing these issues is no different than Khronos asking developers to stick to the OpenXR specification. Per all the work I have done with their plugin in the past, I estimate the effort to fix their plugin is a matter of "days, not weeks".

Step 2): Remove the lockdown to specific OpenXR runtimes. This is trivial once Meta has spent a few days on 1).

Step 3): Everybody wins! Meta continues to deliver their OVRPlugin. Developers can leverage OVRPlugin for the special features they do not find anywhere else. End-users can run applications on any runtime and any platform (OpenXR's primary mission).

The only medium-term investment for Meta is to begin testing their OVRPlugin on more than just Quest Link. This shouldn't be that hard - they can test with SteamVR OpenXR for example - they probably already have a QA pipeline that does such validation.

[mbucchia]

Thank you Rylie. Closing.