A popular reddit thread over the weekend has brought to the surface a long-roiling, behind-the-scenes debate about the future of the nascent virtual reality revival. The questions being debated get into what exactly it means for a head-mounted display to be an "open platform," and who, if anyone, will be able to set critical standards for cross-platform development across VR hardware.

In a sprawling thread started over the weekend in reddit's "PC Master Race" subreddit, user ngpropman pointed to news of Oculus funding roughly two dozen exclusive games for the Oculus Rift's launch as evidence that Oculus is using "console tactics" to push for a "closed ecosystem" for its Windows-based VR peripheral. The implication of the post seemed to be that Oculus is working to lock games away from compatibility with competing VR platforms and that Oculus might end up closing off the entire platform itself from unauthorized software, in the style of Apple's iOS App Store.

Oculus founder Palmer Luckey answered that latter implied criticism quite directly in the thread. "The Rift is an open platform, not a closed one," he wrote bluntly. "You don't need any kind of approval to make games for the Rift, and you can distribute those games wherever you want without paying us a penny." That gels with statements Luckey made in the wake of Oculus' $2 billion acquisition by Facebook last year, when he said, "If anything, our hardware and software will get even more open, and Facebook is on board with that."

As for locking certain games from working on other VR platforms, Luckey was a little less direct. The exclusive games Oculus is funding, Luckey said, are being codeveloped with Oculus staff, and the majority "would not even exist were we not funding them." He didn't completely rule out those titles eventually coming to other head-mounted displays, but he did note that "time spent building and maintaining support for other headsets is time that could be spent improving and expanding content." He added that "trying to support every single headset on the market with our own content is just not a priority for launch."

Translation: we're paying to get these first-party games made, and we're not exactly eager to pay for them to be selling points for our competitors.

Yes, buying exclusives is indeed a "console tactic," and one that console makers have used forever to try to set apart what can otherwise be hard-to-distinguish hardware. But it's not like PC hardware makers haven't done the same thing. Over the decades, Microsoft has funded plenty of Windows gaming exclusives itself, both through in-house first-party studios and third-party partners. The fact that its major OS competitors mostly didn't do the same thing is a large part of the reason that Windows is the de facto standard for PC game development these days, and why upstarts like SteamOS have an uphill battle in trying to unseat it.

Regardless, putting money toward a few exclusives doesn't determine whether or not you have an "open platform." Anyone can still make games for Windows and/or the Oculus Rift without paying the platform holder a fee—and can port those games to other platforms if they wish. The fact that certain developers are giving up that opportunity in exchange for funding and development help directly from Oculus (or Microsoft), doesn't change the overall openness of the platform itself.

Setting the standards

Whether or not any single VR platform is "open" or not, though, may be moot if developers have to juggle countless slightly different development standards for countless slightly different VR platforms. In a way, making a PC game that only works on the Oculus Rift is as ridiculous as making a PC game that only works on Dell monitors.

Situations like that actually existed in the early history of home computing, where the makers of WordPerfect needed to code their own specific printer drivers to work with a variety of peripherals. These days, we've long come to expect this kind of low-level hardware interfacing to happen at the operating system level and for layers like DirectX to smooth out gaming-specific concerns across myriad hardware configurations. (Microsoft could do something similar with a set of OS-level virtual reality APIs in some future version of Windows. Despite collaborative efforts with both Valve and Oculus and work on similar APIs for its own HoloLens, we haven't heard of any such unifying efforts in the VR space coming from Microsoft.)

Virtual reality isn't even close to that level of standardization yet, and it's an open question whether it will get there. Right now, Oculus is focusing on a proprietary Rift software development kit (SDK) that's tightly integrated with its own hardware. The company seems to think that's the best way to ensure the sub-frame-level timing accuracy needed for a convincing sense of VR presence, through a variety of Rift-specific features in the SDK.

While users can download and modify the Rift SDK source code for their own projects, it's distributed under a closed license that prevents redistribution or use with "unapproved commercial virtual reality mobile or non-mobile products or hardware." That's despite very early, pre-Kickstarter writing from Luckey indicating that he wanted the Rift to be completely open source. (On the hardware side, Oculus has distributed the plans for the original Rift development kit in an open source format.)

Valve, on the other hand, is building a more open platform that it says will support multiple headsets from multiple makers, all of which run on Valve's "OpenVR" standard. While the HTC Vive is the first and best known of the SteamVR headsets at this point, the hope seems to be that any headset will be able to work with the same games by making use of OpenVR tools and drivers.

Then there are third-party efforts like OSVR, the Open Source Virtual Reality standard being developed in conjunction with hardware maker Razer. OSVR wants to be the unifying layer that translates input and output data from dozens of different VR hardware makers so that they all work together in harmony.

The idea is to let software makers code for one standard while letting OSVR worry about, say, the slightly different ways that five different VR controllers report their real-world positional data. "If you're a game developer and you can say, 'I'm either developing for Oculus, or I'm developing for Oculus and 19 others' [through OSVR], that's potentially a compelling story," Sensix CEO and OSVR evangelist Yuval Boger told Ars Technica in a recent interview.

There's plenty of impetus for hardware makers to integrate with the standard, too, Boger says. "On the hardware side, if you are the 11th eye tracking vendor, I'd say, 'Hey, you just need to plug in to OSVR and now you can enjoy all this content,' as opposed to having to go to the publisher and say, 'Please, please, please support my thing in your application.'" OSVR currently lists 118 "supporters" for its technology on both the hardware and software side, includng Steam's own OpenVR initiative.

Luckey isn't too impressed with these efforts to standardize and generalize the VR space just yet, though. "As a concrete example, SteamVR is currently (and has generally been) pretty much broken when it comes to Rift support," he wrote in the reddit thread. "When it does work, support through SteamVR is far behind our own SDK. It is pretty clear that they have been prioritizing Vive, and that is fine. They are working hard to launch a product as well, and it makes more sense for them to focus on improving their own side of things than to try keeping up with every update we make. At the same time, it shows why relying on someone else to keep things working can be tricky."

Simply plugging a new VR headset into a computer isn't the same as plugging in a new monitor, Luckey argued. Supporting a new headset "requires pretty deep integration into the code of the game, integration that the developers themselves have to spend a lot of time integrating and updating," he wrote. "This is especially true for games that rely on our SDK features like timewarp, direct mode, late latching, and layered compositor to get a good experience."

Does that mean we're doomed to a fragmented future, where developers have to make ten versions of a game for ten slightly different VR headsets and controllers? Not necessarily. Luckey said the ability to open up VR development across hardware "will happen eventually, especially as the technology matures and open standards are created."

For now, though, he wrote that "true open standards are going to take cooperation between all the major players in the PC gaming space, [and] that role cannot be fulfilled by any 'open standard' that is controlled entirely by a single company. We very much are cooperating with major players in the space, from GPU vendors to OS creators to game developers—lack of immediate participation in any of the single-vendor controlled universal SDKs that have popped up recently (after we have spent years making our technology the best) is not an indicator of us doing anything wrong in the near term or long term."

So just how "open" will the future of virtual reality on PCs be? The answer depends largely on what succeeds in the marketplace. If something like the Oculus Rift become the de facto standard for tethered VR, its SDK could be the proprietary lifeblood of development in the same way that DirectX is on Windows. If other headsets make their mark, though, competing open standards may eventually coalesce into a single development environment that works on pretty much any compatible hardware.

Neither of these scenarios envisions a "console style" future where one company controls all the software on its headset, but the result could still have major implications for the future of virtual reality development.